[REBOL] Re: Bug! in assignment to date! values with stacked set-path values
From: lmecir:mbox:vol:cz at: 18-Nov-2002 16:37
Hi Romano,
> > > The result is a strange behaviour: a set-path which works like a path
> > >
> > > x: func [/b][3]
> > > type? first [x/b:];== set-path!
> > > x/b: ;==3
> >
> > This is unexpected, but it may be justified as an attempt to "do
something
> > meaningful" instead of firing an error.
>
> I do not think the same. Here the attempt is not set something, but only
to
> evaluate the path. If a set-path is by default "set the value referenced
by
> the path" this construct should trigger an error or a crash. Obviously
this
> can be corrected adding an error! ad hoc, but ist shows for me the
interpreter
> behaviour.
Yes, you are right. This shows the way how the interpreter is built.
Nevertheless, there are at least two cases, when I would consider it a bug.
The first one is the subject of this thread and the second one is the case
of two-times-fetched functions.
> Often I'm asking myself: what are advantages of refinements in functions?
> Often i see only the bad side.
The refinements have big disadvantages, as I see it.
Some disadvantages:
1) the function must test, how it has been called, although that information
has already been processed to get the arguments
2) the refinement system works well only if any refinement combination is
legal
, otherwise the function must check the combination on its own
The trouble is, that the refinements have advantages too.
The main advantage is a lower pollution of the system dictionary.
