[REBOL] Re: object funnies
From: rgaither:triad:rr at: 19-Oct-2001 16:50
I most heartily agree with the points below. I was not advocating
a change as necessary but rather defending the observation that
the behavior wasn't intuitive. Something rather hard to quantify I
admit.
I have the problem of wanting to use the language for much larger
tasks than you are suggesting and thus "have" to deal with these
issues. This can be done, and even done well - or I wouldn't still
be working with REBOL - but it requires more effort than I would
like at spots and a shift in how a problem is approached that makes
for slow going some times.
Thanks, Rod.
>> As for a BASIC reference you would be in big trouble if that was your
>base of judgement of other "old" languages! :-)
>
>LOL. Agreed. I like to think I judge each different language on its own
>merit, and having been exposed to several very different languages (more
>than I am actually fluent with) I tend not to assume behaviors from one
>language to the next. Thus I am not bothered by the default behavior of
>using the global context because that seems to be the REBOL way.
>
>I can also understand and even agree with your more professional point of
>view of creating larger projects and the software engineering principles
>involved. But, changing this behavior of REBOL may be opening up a can of
>worms. If variables are scoped locally by default, now I need a way to
>specify that I want my variable to be visible outside the context - like
>"extern" in C. We now have it the other way around. And what about
>persistent local variables? That also seems to fall in this same topic.
>Wouldn't we need the introduction of additional syntax to specify these
>things? (uuuhhgg, syntax)
>
>Scaling REBOL to cleanly handle these necessary SE issues would be a
>challenge, I think. IMO REBOL was not targetted for this, based on the
>current functionality of the language. I've always thought of REBOL as a
>language to "Keep simple tasks simple." This implies small tasks and
>programs, where these deeper programming issues do not surface.
>
>- Michael
>
Rod Gaither
Oak Ridge, NC - USA
[rgaither--triad--rr--com]
