This is where Object Oriented programming can be useful. If you define a
Trait and then several abstract classes extending the trait at many levels,
it will be
possible to define complex polynomial ( p(x)=det(A-x*B) ) specific abstract
classes at deeper levels for computing coefficients. OOP constructs will
make super-classes and traits to be reusable for lower level abstract
classes. A type or operations on a type can both be abstract.
Mathematicians
can exploit the power of OOP if the nested structures in mathematical
expressions are understood properly for writing programs.
On Wednesday, October 21, 2015 at 12:43:17 PM UTC-7, vav...@uwaterloo.ca
wrote:
>
> Earlier I posted a statement in this thread that object-oriented
> programming is in many cases not suitable for scientific software because
> it forces the designer to make decisions too early in the design process
> that become unwelcome constraints as the project progresses.
>
> If I understand what people are saying about traits, they may pose the
> same danger. Just to give a simple example, suppose you are designing a
> class for univariate polynomials over a ring K. You might expect that you
> will need both dense and sparse (i.e., most coefficients=0) polynomials, so
> you might create an abstract class for both dense and sparse polynomials.
> In current Julia you might write:
>
> abstract UnivariatePolynomial{T}
>
> where T is the underlying ring. You would specify nothing else. Now if
> 'traits' were available as a language feature, you might create a member
> function "obtainCoefficient" that would work properly for both sparse and
> dense polynomials.
>
> But the next week, someone asks whether you can handle polynomials
> specified as p(x)=det(A-x*B), where A and B are n-by-n matrices. For
> polynomials in this format, "obtainCoefficient" is expensive and would not
> be regarded as a simple "getter" operation. If many people had already
> written functions invoking the 'obtainCoefficient' method, then you would
> be stuck. You would retrospectively realize that the obtainCoefficient
> member function was not a good idea. This example is typical of open-ended
> scientific software projects.
>
> So again, I would be wary of adding object-oriented features to Julia, at
> least until the language matures a bit more mature.
>
> I have been on the other side of this fence already: I wrote the code for
> SortedDict in DataStructures.jl. I had a mandate from Kevin Squire to make
> SortedDict a drop-in replacement for Dict. Since there is no formal
> interface for 'Dict' defined, and indeed, Julia does not have a means to
> specify interfaces, this means that I actually have to read all the code in
> associative.jl and dict.jl in order to carry out Kevin's mandate. But this
> turns out to be not so hard!
>
> -- Steve Vavasis
>
>
>
>
>
>
> On Wednesday, October 21, 2015 at 1:00:25 PM UTC-4, Tom Breloff wrote:
>>
>> I think this discussion shows complementary definitions of traits:
>>
>> - verb-based traits: a type agrees to implement all the verbs
>> appropriate to the given "verb trait"
>> - noun-based traits: a type agrees to contain certain underlying data
>> (and thus the getter/setter verbs could be implicitly defined for those
>> fields)
>>
>> Whatever the final implementation of traits in Julia, I think keeping in
>> mind this distinction could be helpful.
>>
>> On Wed, Oct 21, 2015 at 12:42 PM, Stefan Karpinski <ste...@karpinski.org>
>> wrote:
>>
>>> On Tue, Oct 20, 2015 at 7:00 PM, Brendan Tracey <tracey....@gmail.com>
>>> wrote:
>>>
>>>>
>>>> > Above, a relatively simple macro can replace all the "Type..." with
>>>> the fields of the composed types, applying multiple inheritance of the
>>>> structures without the baggage required in classic OOP. Then you can
>>>> compose your type from other types, but without having to write
>>>> "unicycle.wheel.radius"... you can just write "unicycle.radius".
>>>>
>>>> As Stefan mentioned, Go is not traditional OO. This "composition-based"
>>>> approach is part of Go's OO approach. In go, a type can have named fields
>>>> of different types (like most OO languages), but also has "embedding". For
>>>> example, if one declared
>>>>
>>>> type Unicycle struct {
>>>> Wheel
>>>> Frame
>>>> Seat
>>>> }
>>>>
>>>> then you could access the individual fields directly. So, if "u' is of
>>>> type Unicycle, then you could access/set u.Cushiness directly. Similarly,
>>>> if the embedded types had methods, i.e. frame.Color(), they can be called
>>>> directly through unicycle, u.Color(). This is similar to, but distinct
>>>> from, inheritance (the difference is that the Unicycle type doesn't
>>>> actually have these fields, just the ability to call them easily, which is
>>>> significant because of interfaces). In the case of clashes, the program
>>>> must specify which is meant, so if both Seat and Frame had a Color()
>>>> method, the user would have to specify u.Frame.Color vs. u.Seat.Color. In
>>>> Go, this is handled by the compiler, and would need to be handled
>>>> somewhere
>>>> in the Julia runtime/REPL. It's a very nice paradigm, but would have to be
>>>> made to fit within the broader Julia context.
>>>>
>>>
>>> I do like this approach to composition/delegation, but it requires
>>> automatically adding a lot of methods to the delegator, i.e. Unicycle in
>>> this example, from all of its components, which feels kind of nasty and
>>> dangerous, especially since we allow dynamic addition of methods
>>> after-the-fact. In other words, you might add a method to Wheel, Frame or
>>> Seat at any time, which would presumably then also apply to Unicycle
>>> objects, potentially with unexpected consequences. It would be nice if the
>>> delegation was more limited than that. Go doesn't have this problem since
>>> you can't dynamically add methods – everything is known at compile time.
>>>
>>
>>
