Having . as a normal operator equivalent to `-> instead of `[] would make more sense than the current situation.
I doubt that there is a lot of code depending on . beeing `[] and not `->.
I think there's a significant amount of such code, written by people for which the distinction has been clear. Changing the convention from [] to -> for modules is just an unnecessary source of confusion in my view.
I have nothing against allowing . in normal expressions, but it should be an alias for [], not ->.
From a more designwise perspective, I consider [] to be the index
operator of the "data level" while -> is on the "meta level". I.e. if one implements some kind of intelligent mapping class, it's natural to use [] to index the elements in the "mapping" while -> is used to get the extra functionality in the object itself. Dir- and joinnodes follows this design principle.
Unfortunately it's a bit muddled by the fact that [] and -> are equivalent on real mappings. It'd be cleaner if -> was kept undefined so that it could be used for meta functions on mappings. Then we wouldn't have to have a global set_weak_flag function, for instance.
Still, this muddling doesn't make the principle less useful in cases where [] and -> both can do different meaningful things.
Personally I would not mind
string s = "foo"; s.size() -> 3
But this is impossible if . is mapped to [].
s->size() -> 3 would work, though, but people would probably try to use . and get confused. :-)
I'd also prefer if "->" was spelled "." to begin with, but now we're using "->" and there's not much to do about it.
why would they try .? the average user would use . only on modules, a string is certainly not a module but more of an object.
greetings, martin.
I don't agree that accessing a function/class in a module is a "data level" operation, as opposed to a "meta level". So any muddling is probably more due to the fact that . uses [], not ->.
It is clearly a "data level" operation from the perspective of the dir- and joinnodes, whose own functions and stuff are the "meta level".
The confusion here is that when one cease to use . then the internal workings of the resolver machinery aren't hidden anymore. If one were to rewrite the dirnode stuff completely so that those objects actually _are_ the module objects then it'd be another matter and I'd agree -> should work on them.
But that's not the case currently, so what we're left with is that the join- and dirnodes do show and one has to be aware of them if one starts doing stuff like this. In other words, users on this level must be aware that modules can be join- or dirnode objects and that there accordingly is a distinction between "data" and "meta" levels when using them.
Another example is that inheriting a directory module or a joined module doesn't do what one want at all.
All your examples is more or less bugs, though.
Why should the user be forced to distinguish between dir and joinnodes, especially as there is no way to actually know which is which without looking at them rather closely in hilfe. It's not in the documentation.
Yes, they can be seen as bugs, or perhaps misfeatures. As I said, if someone really _fixes_ the problem and do away with dir- and joinnodes completely so that the objects returned by the resolver actually implement the real modules, then by all means should -> work as it does on nonjoined file modules.
But until then, those objects are there and one better be aware of them. Trying to cheat around with `-> only adds confusion and complicates things.
Why should the user be forced to distinguish between dir and joinnodes,
I assume you mean distinguish between these objects and real modules which you'd get for nonjoined file pmod:s.
Most of the time the user doesn't have to bother if (s)he sticks to either . or []. [] works fine on real file pmods.
But in other cases: Because, with the current implementation, (s)he has to - see above.
especially as there is no way to actually know which is which without looking at them rather closely in hilfe.
Is done in the same way as most other object recognitions: foo->is_resolv_dirnode or foo->is_resolv_joinnode.
It's not in the documentation.
You're probably right. The documentation can be improved.
pike-devel@lists.lysator.liu.se
-
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) ＠ Pike (-) developers forum -
Martin Bähr -
Martin Stjernholm, Roxen IS ＠ Pike developers forum
-
Per Hedbor () ＠ Pike (-) developers forum