ralph wrote:
If the syntax for passing it to a sub
remains as verbose as it currently is,
you are probably right that it won't
be used to achieve brevity!
You're confusing brevity of declaration with brevity of use.
Declarations should always be relatively verbose.
Why do you think your
Mark J. Reed wrote:
Attributes are class-specific for a variable (okay, class instance
specific, if you do Evil Things with multiple copies of a single base
class in different legs of the inheritance tree and override the
default behaviour of the engine) and not queryable at runtime without
Luke Palmer wrote:
Could you just look through the lexical scope of the object?
for $this.MY.kv - $k, $v {
print $k: $v\n
}
Or would you look through the class's lexical scope and apply it to
the object?
for keys $this.class.MY {
print $_: $this.MY{$_}\n
}
I
Nicholas Clark wrote:
We're looking for a word that tersely expresses
has_no_side_effects_and_can_safely_have_its_results_cached_based_on_parameter_types_
and_values_and_calling_context ?
And to people in the perl5 know, Memoize is the module that implements this,
hence why people who know
Paul Johnson wrote:
Part of the reason I would prefer something like pure over something
like cached is because it describes the function rather than telling
the compiler how to deal with it. That feels better to me. It's
working at a higher level. Maybe the end result is the same, or maybe
Arcadi wrote:
this is not a description or definition of something. It is just set
of questions and confusions that I have when I encounter words like
variable , name , alias, assign in perl . In the form of
explanation. But actually these are questions .
These are answers. In the form of
On Monday, November 11, 2002, at 02:19 AM, Damian Conway wrote:
One of the reasons I like Ccached is because it does specify
exactly the way the subroutine is to behave (i.e. be called the first
time,
and not called every subsequent time the same arguments are supplied).
So
I can do
You're confusing brevity of declaration
with brevity of use.
One needs sufficient brevity of both call
and declaration syntax if the mechanism's
brevity is to be of use in short scripts.
Making (limited) circumvention of [$_'s
lexicality] depend on a verbose and
explicit syntax will help
ralph wrote:
So what is driving you
guys to deliberately avoid a brief def
syntax?
Can't speak for Larry. But what's driving me is the desire
to balance conciseness with comprehensibility, and to keep the
overall cognitive load manageable.
If you're proposing that there be some special
method f ($self : $a) { ... }
sub f ($a) is given ($line) { ... }
what do you call $self
The invocant.
and $line?
A lexical variable that happens to be
bound to the caller's topic.
The invokit perhaps?
placeholders create subroutines, not methods.
Oh.
Are
10 matches
Mail list logo
