On Sun, Nov 18, 2007 at 05:45:02PM +0000, Martin Nilsson (Opera Mini - AFK!) @ Pike (-) developers forum wrote:
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?
i can't think of a case that would benefit from that.
if a symbol is readable or writable, like in this example:
protected void foo; public int `foo() { return x; } private void `=foo(int y) { x = y*2; }
then it should be visible, seperating that would only add the ability to make invisible public symbols or publicly visible private symbols. both seem to only create confusion without gain. what i am i missing?
Adding a method for deprecating methods and symbols. [weak, shared] int f(); @weak @shared int f(); weak shared int f();
The conclusion was that further studies needed to be done to solve the new keyword issue. This was not considered a problem for introducting a new deprecation method though, as it was not something anyone was concerned about the looks for. The agreed upon new keyword is __deprecated__,
i had the impression that this was just another syntax suggestion or a suggestion for a convention. i don't mind either way. the __ make the keyword stand out and make me feel like not wanting to use it, which is probably a good thing. deprecating things should be done rarely and with a lot of consideration only.
- 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.
One item that was discussed during the last day, and thus didn't make the "official" list of 7.8 items was how zero_type/UNDEFINED worked in Pike.
mapping m = ([ "y" : UNDEFINED ]);
Here the expression m->y will return 0 with zero type 0. This is due to all subtype flags being cleared by the mapping. For symmetry with with the object case this was agreed to to be changed.
does this mean that UNDEFINED becomes a generally storable value?
how will the behaviour be with arrays or multisets?
zero_type(({ UNDEFINED })[0]); // this is 1 array a = ({ UNDEFINED }); zero_type(a[0]); // this is 0
zero_type(indices((< UNDEFINED >))[0]); // this is 1 multiset m = (< UNDEFINED >); zero_type(indices(m)[0]); // this is 1
seems like multisets can store UNDEFINED already.
greetings, martin.