Dan Sugalski writes:
> Consider yourself officially drafted. It's too late to run away... :-)
Affirm that, Sir! :-)
/acy
I read *all* of Camel 1, it was a slim volume and gave (correctly) the
impression that Perl is an easy to get into language that is useful for
loads of things.
You can justifiably still say those things about Perl -- but it's not the
impression you get; and the impression is a lot of what counts.
At 11:27 AM 5/22/2001 -0400, Bryan C. Warnock wrote:
> From a design perspective, are they (bytecodes and opcodes) different, or is
>it simply a structure (linear vs tree, for instance) distinction? Would
>the above cover the execution engine, the data dumper/restorer, or both?
They're definitel
At 06:36 PM 5/21/2001 -0700, A. C. Yardley wrote:
>What I propose is perl6-internals (or, per Dan, "the bytecode
>definition group") adopt the above format for the PDDs on certain
>aspects of Perl6's interpreter (i.e., again, per Dan, "assembly
>language standard, ...").
We'll need to work from a
On Tue, May 22, 2001 at 10:10:55AM -0500, Garrett Goebel wrote:
> What is UNIVERSAL::can($foo, 'new') going to return if there is a variable
> and/or value property 'new' set on $foo?
undef if there is no "new" method.
> To my knowledge, no one has yet proposed how you can clear a user-defined
>
On Monday 21 May 2001 21:36, A. C. Yardley wrote:
> B>
> This section gives detals on how the instruction is laid out in the
> bytecode of a class file. It shows a table listing the opcode for
> the instruction, as well as any additional parameters that follow
> the opcode in bytecode.
>
> B
From: Graham Barr [mailto:[EMAIL PROTECTED]]
> On Tue, May 22, 2001, Damian Conway wrote:
> > > if so, then wouldn't it be safer to put properties
> > > inside a special object associated with each object
> > > (the 'traits' object) so there would be little
> > > namespace collision?
> >
> > We
At 09.46 -0500 01-05-22, Garrett Goebel wrote:
>I would rather the bike shed be painted:
>
>@var_prop = keys $foo.is;
>@val_prop = keys $foo.value.is;
The btw/prop/value_is/variable_is/is method(s) will return a
reference to the properties hash, so Perl 6 will certainly support
getting the keys
On Tue, 22 May 2001, Graham Barr wrote:
> On Tue, May 22, 2001 at 12:29:33PM +1000, Damian Conway wrote:
> >
> > We actually want the possibility of that kind of namespace collision:
> > for polymorphism.
>
> Many people keep bringig this up as a confusion and you give the same reply.
>
> Wi
From: Carl Johan Berglund [mailto:[EMAIL PROTECTED]]
>
> Other than that, I think I like Larry's idea to have one variable_is
> and one value_is method. I would also very much have Data::Dumper
> built in as 'dump', so that I could say
I would rather the bike shed be painted:
@var_prop = keys
At 08.53 +0100 01-05-22, Graham Barr wrote:
>With the current approach I can see most code accessing properties
>with $var.prop{name}
>because they want to make sure they get the property and not a method, whereas
>it would be shorter, in the common case, to have something like $var'name
I woul
On Tue, May 22, 2001 at 12:29:33PM +1000, Damian Conway wrote:
>> if so, then wouldn't it be safer to put properties inside a special object
>> associated with each object (the 'traits' object) so there would be little
>> namespace collision?
>
> We actually want the possibility of th
12 matches
Mail list logo
