in reply to Re: Benefits of everything is an object? Or new sigils?
in thread Benefits of everything is an object? Or new sigils?

Thanks for this reply, it deepens the meditation into new dimensions worth at least one new thread. :-)

Unfortunately I can't spend as much time to reply here like I did for other posts in this thread.

> That's why I spend so much time sketching data structures on paper before I touch the keyboard.

So do I, but sometimes its better to just start to code with the intention to prototype the real thing. And even in prototyping the Javascript approach is less painful than Perl.

> I would also argue that one ought not use blessed array refs as objects.

I disagree, maybe I'm too influenced by Conways OOP book but I see Perls possibility to bless any ref as the advantage of this (maybe too?) flexible OO System.

After tieing the array to a new class, push() will act however you want it to act, e.g. the data can be easily inside out. I can't see why a blessed arr_ref should act differently to a blessed hash_ref, so no need to worry about ugly side effects.

> But I have a difficult time with a plural object.

IMHO this "plural naming convention" is a workaround for missing sigils. Actually I spend too much time to invent clear plural names where I would prefer to simply set a sigil.

Normally I have my own hungarian notation writing something like $A_employees or $employees_ar to denote the nature of the variable. Contrary to PBP I prefer the former, because I want to know what I'm dealing with at one glance and _one_ end of the word , not on both ends. And Perl favors the beginning...

> I expect the sigils only to tell me what will happen; not what the author's intent may have been. For the latter (since I'm not that good), I'll read the comments.

I agree to a certain point, the sigils should be very clear about context and data type.

I think mentioning Perl 6 was misleading...I'm also not happy about hash-slices which start with a $! :(

In my vision these sigils should only be in scalars context, such that €employees == $employees is always true.

The differences I'm meditating of are

  • functions with prototype (@) should allow €-variables without compiletime error, such that

    push €employees, "elem" is possible

  • it should be allowed to call a CORE::builtin as a method, without performance penalty, such that €employees->push("elem") does exactly the same thing like push €employees, "elem" and vice versa. When push was altered by tieing or overloading CORE::push this should be transparent.

    <UPDATE> Allow me to give an example from another language ... (won't name it here ;-) 

    >>> a=[1,2,3]
>>> len(a)
3
>>> a.__len__()
3

    [download]

    (Here Guido punishes the use of a method (!) by appending 4 extra underscores. We don't need that ... :) </UPDATE>

  • it should be possible make the dereferencing arrow -> optional and to write  €employees[1][2] instead of $employees->[1][2] ( the same like the second -> is already optional in €employees->[1]->[2]

  • when the "list form" of the array is wanted, this should be achieved if and only if an @ was prepended.

    Such that @{€employees->[$idx_phonenumbers]}[0..1] is the sliced list of the first 2 phonenumbers.¹ ²

  • I would like to swap the precedence rules to avoid the frequent need of curlies.  @€employees[$idx_phonenumbers] is equivalent to @{$employees->[$idx_phonenumbers]} and not to @{$employees}[$idx_phonenumbers]. If you really need the latter - which is an array slice - you should still be able to write @$employees[LIST]

  • I would love to have extra checking under strict and warnings, to assure that €employees is _really_ an array_ref. For instance €arr=\%hash should cause an error at compile time. A kind of type checking if you want. Assigning a "wrong" scalar type at run time should also cause an error. So if you want to achieve a list assign @arr=$a you need to prepend an @ : @€arr=$a

    Please note, the use of the euro symbol is of course a matter of debate, actually there are some currency symbols ( like $ ) available in Latin 1 AND Western Keyboards, like £, ¢, ¥ and ¤ (the latter is often mapped to €). 4 new symbols should be enough to cover the known ref types: arr_ref, hash_ref, code_ref and scalar_ref.

    (I'm not sure if there is a need for a symbol for blessed refs...)

    All of what I sketched here should of course be voluntarily activated with something like use refsigils

    • I see plenty of advantages in this approach...

    Cheers Rolf

    ¹) this is a contrived example, I know that a hash with key "phonenumbers" is a better choice than using an array with an index $idx_phonenumbers! :)

    ²) there's another possibility to be mentioned, IIRC Perl 6 allows a slice to be called with "method syntax"  ->@[LIST] (of course in Perl6 with a point and not an arrow ;)

    In Section Meditations