> > Also there was a discussion about how modifiers should be handled.
> > Currently the actual getter and setter functions are made private
> > and the "union" of them are used as the visibility for the virtual
> > symbol. This was argued against at the conference
>
> could someone please repeat the rationale for changing that?
> martin stjernholm?
Ok. The reason is mainly to be consistent:
All other lfuns (`+, create, __hash, etc) are normal functions in this
sense; they define an identifier with a normal declaration and the
modifiers apply to that function, not the special characteristic it
also enables. E.g:
class X (int n)
{
private X `+ (int n2) {return X (n + n2);}
}
Here the function `+ is made private, but not the ability to use the
object in an addition; you can still do X(3) + 4. I think this should
apply to these functions too.
The argument has been raised that it never would be interesting to
call the setter and getter functions with their function syntax (i.e.
`foo=(17) or x->`foo=(17)), but to that I respond: Prove it. All other
special functions have been useful in function form, so it's not safe
to say these would never be useful that way. And if they are used in
function form then it follows that it's interesting control access to
them too.
Another reason is that other modifiers of a completely different
nature could be added in the future. In that situation we could get
into the murky situation that some modifiers apply to the functions
themselves while others apply to the symbol, or maybe both.
A third reason is that it completely avoids the ambiguity when the
getter and the setter are given different visibility. Which visibility
should apply to the "virtual variable" in that case?
Following this reasoning, modifiers should apply to the getters and
setters themselves and the "virtual variable" should always be public.
That I think would work well, but in case the virtual variable needs
protection, it could be solved using the void declaration syntax. I
don't consider that very important to fix right away, though.
> > 7. Martin Stjerholm wanted his work with Locale.Charset.EncodeError /
> > DecodeError to be finished before 7.8.
>
> could you elaborate what needs to be done here? it sounds like something
> that doesn't require indepth experience with the pike internals.
The job is mainly to fix the Charset module to actually throw these
errors. It's just a SMOP.
