[REBOL] Re: : Pure OOP project ?
From: chrismorency:videotron:ca at: 9-Apr-2002 19:43
> I've been doing OOP stuff heavily for the past 7 years (though
> and Eiffel folks could argue about the OOP-ness of it :) and I'm
> amazed at the code I find myself writing in REBOL compared to what I would
> have written before.
I daily think in C, Smalltalk and Rebol. I constantly find myself saying,
In rebol I would...
, "In smalltalk I would..." and "In C I could but...".
The thing with Rebol is that it's small, it's fast, it's multi-platform ! I
am too amazed at the way I code in Rebol. It's so simple... and it works !
The only problems I have encountered is with VID, but that may be more
because of my laziness ;)
> IMO, of the "big 3", Encapsulation provides 49.5% of the value,
> is 49.5%, and Inheritance the rest. :) These, of course, are my opinions
> based on my experience. YMMV. For large projects, the value of
> goes up. The judicious use of Polymorphism can help to keep projects from
For me, of the "big 3", Encapsulation provides 45%, Inheritence 45% and
polymorphism 10%. Of Encapsulation, I would say that the "data access" value
is 80%, private/public 20%... Personnally, I find the late to be something
more of alerting the developer to what he is doing... but otherwise, he
should know !
For Rebol, I don't think encapsulation (private/public) is that important.
Inheritence, polymorphism and data-access is more important and is already
implemented with the make object! object. Some may argue that when
super-object's behavior has changed, sub-objects should too... I don't even
think that's the problem. My main problem with the current implementation is
that code is copied from instances to instances (sub-objects!)... Anybody
ran stats on memory consumption with objects ?
If methods would be objects in Rebol and would make the difference between
the self of the object and the self of the method ! Maybe all this could be
resolved with a new datatype? for Core 2.6 ?
> I've always liked the ability to provide optional arguments. Like other
> features, it can be abused, but, done right, they can help to reduce the
> number of routines you have to deal with and actually provide
> quite a bit of
> value. For example, I have a ROUND function that has *6* possible
> refinements (with one of them probably going away as it's semi-redundant
> with another). Normally I would run screaming from something like
> that but I
> looked at the alternative and like this solution better. Here's
> the help for
I grok how refinements can be useful ;) I've used them myself, and for
programming, it's really awesome, but for objects... hmm I'm