Juerd wrote:
$y() = 7;
No, sorry, that looks to me as if $y is a reference to an lvalue sub,
not like any form of referencing of scalars.
I think it will come naturally to the C++ and Java folks. There the
accessor kind of functions is either mapped into the name get_y()
and set_y(value), or
On Thu, Jun 02, 2005 at 10:45:45PM +0200, Juerd wrote:
> If we allow "sub .foo", "sub :foo" comes naturally, and another
> asymmetry is gone.
>
> It would also allow "multi sub" and "multi method" to simply become
> "multi".
I _really_ like the explicit 'method' name that methods have. Calling
t
"TSa (Thomas Sandlaß)" skribis 2005-06-02 22:22 (+0200):
> The only thing that is a bit unclear to me is if the dot is part of the
> operator name---like a sigil---or purely syntactical. A method is e.g.
> also not defined with the dot:
> class Blahh
> {
>method .example ( $non_invocant ) {...}
HaloO Juerd,
you wrote:
Except that () doesn't return a reference to an anonymous scalar of the
list it surrounds.
Of course not. The inside of the .() call operator has type
Signature and the dispatch goes to the implementation that has
the closest type distance to the types of the actual arg
"TSa (Thomas Sandlaß)" skribis 2005-06-02 21:30 (+0200):
> And it nicely lines up with $y[], $y{}, @a[], %h{} etc. as
> dereferential expressions.
Except that () doesn't return a reference to an anonymous scalar of the
list it surrounds.
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http:
Juerd wrote:
$y() = 7;
No, sorry, that looks to me as if $y is a reference to an lvalue sub,
not like any form of referencing of scalars.
Well, it is a reference to an lvalue sub if it is just that :)
As unspecificly typed as it stands there it could be anything
that reacts to &postfix:<()>
"TSa (Thomas Sandlaß)" skribis 2005-06-02 20:36 (+0200):
> Might it be applicable to use .() as the dereferencer
> of scalar variables that derefs to the next none(Ref)
> type and if that is a Code it dispatches to it as expected?
Or perhaps postfix $, to deref recursively.
my $foo = 5;
Luke Palmer wrote:
When we heard that Larry didn't acutally want $$foo to infinitely
dereference, some of us were overjoyed, and others severely
disappointed. Both transparent dereferencing (infinite $$foo) and
opaque dereferencing (one-level $$foo) have their uses, but they are
definitely disti
Juerd wrote:
Thomas Sandlass skribis 2005-05-28 17:34 (+0200):
I propose %hash = { key => :\$variable, foo => 'bar' };
:\$variable looks like many things to me, but not an alias.
Let's forget that idea, because I have a bunch of better ones!
$hash = { key => \ $variable but rw , foo =
"TSa (Thomas Sandlaß)" skribis 2005-05-30 8:58 (+0200):
> [This is a repost, somehow it didn't get through before, sorry.]
This is the fourth time it did get through to my mailbox, at least.
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http:/
[This is a repost, somehow it didn't get through before, sorry.]
Luke wrote:
> Both transparent dereferencing (infinite $$foo) and
> opaque dereferencing (one-level $$foo) have their uses, but they are
> definitely distinct.
Well, they are more like variations on a theme.
> Instead of adding d
Thomas Sandlass skribis 2005-05-28 17:34 (+0200):
> >%hash = { key => undef, foo => 'bar' };
> >%hash := $variable;
> >%hash = 5; # $variable is now 5 too
> Sorry to interrupt, but wasn't {} not derefed when assigned
> to a % variable? Don't get me wrong, I like this meaning. And
> it
Juerd wrote:
> The only real problem with having only infix := for binding, is that you
> can't easily use an alias (aka transparent reference) in a list. You can
> have an array of aliases, but it's harder to have an array or hash in
> which one element is an alias. Binding can be done explicitly:
Luke wrote:
> Both transparent dereferencing (infinite $$foo) and
> opaque dereferencing (one-level $$foo) have their uses, but they are
> definitely distinct.
Well, they are more like variations on a theme.
> Instead of adding different syntax for each
> kind, I'll propose something different:
Luke wrote:
> Both transparent dereferencing (infinite $$foo) and
> opaque dereferencing (one-level $$foo) have their uses, but they are
> definitely distinct.
Well, they are more like variations on a theme.
> Instead of adding different syntax for each
> kind, I'll propose something different:
Luke wrote:
> Both transparent dereferencing (infinite $$foo) and
> opaque dereferencing (one-level $$foo) have their uses, but they are
> definitely distinct.
Well, they are more like variations on a theme.
> Instead of adding different syntax for each
> kind, I'll propose something differen
Brent 'Dax' Royal-Gordon wrote:
Juerd <[EMAIL PROTECTED]> wrote:
There is no way to get an anonymous rw scalar, is there?
There's always the Perl 5 hack:
\do { my $x }
Although that's not truly anonymous, I suppose.
There's a less-well-known hack that *is* truly anonymous:
$ano
Juerd <[EMAIL PROTECTED]> wrote:
> There is no way to get an anonymous rw scalar, is there?
There's always the Perl 5 hack:
\do { my $x }
Although that's not truly anonymous, I suppose.
--
Brent 'Dax' Royal-Gordon <[EMAIL PROTECTED]>
Perl and Parrot hacker
On 5/27/05, Juerd <[EMAIL PROTECTED]> wrote:
>
> There is no way to get an anonymous rw scalar, is there?
Can't the [] and {} syntaxes be considered aliases for new Array(...)
and new Hash(...)?
my $x := new int = 10; # looks like it should work
Ashley Winters
Juerd skribis 2005-05-28 1:15 (+0200):
> There are named arrays, @foo, and anonymous arrays, [].
>
> There are named hashes, %foo, and anonymous hashes, {}.
>
> There are only anonymous pairs. You can't dereference a pair, or bind a
> name to it.
I forgot an important one:
There are named sca
Luke Palmer skribis 2005-05-27 20:59 (+):
> Opaque references always need to be explicitly dereferenced (except
> for binding an array to an array reference, etc.). Transparent
> references always automatically dereference. The decision of what
> type of dereferencing will go on is left up to
21 matches
Mail list logo
