Hi Gregg, > I've been doing OOP stuff heavily for the past 7 years (though > SmallTalkers > and Eiffel folks could argue about the OOP-ness of it :) and I'm > constantly > 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, > Polymorphism > is 49.5%, and Inheritance the rest. :) These, of course, are my opinions > based on my experience. YMMV. For large projects, the value of > Encapsulation > goes up. The judicious use of Polymorphism can help to keep projects from > growing. 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 > it. I grok how refinements can be useful ;) I've used them myself, and for "procedural" programming, it's really awesome, but for objects... hmm I'm not sure... Best, Chris -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with "unsubscribe" in the subject, without the quotes.
