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.
- 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.