[perl #128010] [BUG] reference to outside function prevents role instantiation
# New Ticket Created by grond...@yahoo.fr
# Please include the string: [perl #128010]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=128010 >
In file A.pm6 :unit class A ; our sub f {}
In file B.pm6 :unit role B ; use A ; &A ::f ;
$ perl6 -I. -e ‘use B ; class :: does B {} ;’
===SORRY!=== Error while compiling -e
Could not instantiate role 'B':
Cannot find method 'package_at_key': no method cache and no .^find_method
at -e:1
Notice that &A ::f is not even called, only its reference is used in void
context.
Also notice that without explicit compilation units it works fine :
$ perl6 -e ‘class A { our sub f {} } ; role B { &A::f } ; class :: does B {} ;’
[perl #109880] [BUG] Something is wrong with instantiation of generic roles and typed attributes in Rakudo
As a status update: This behaves differently now.
$ perl6-m -e 'role Foo[::T] { has T @.a = [T] }; class Bar {}; say
Foo[Bar].new.a[0]'
Type check failed in assignment to '@!a'; expected 'Bar' but got 'Array'
in method REIFY at src/gen/m-CORE.setting:9935
in method reify at src/gen/m-CORE.setting:8543
in method gimme at src/gen/m-CORE.setting:9024
in method sink at src/gen/m-CORE.setting:9513
in method BUILDALL at src/gen/m-CORE.setting:1043
in method bless at src/gen/m-CORE.setting:961
in method new at src/gen/m-CORE.setting:947
in any at src/gen/m-Metamodel.nqp:1510
in block at -e:1
$ perl6-m -e 'my $r = role Foo[::T] { has T @.a };
$r.HOW.attributes($r).perl.say'
(Attribute.new(),)
$ perl6-m -e 'my $r = role Foo[::T] { has T @.a }; $r.HOW.attributes($r,
:local).[0].type.HOW.archetypes.generic.say'
1
[perl #109880] [BUG] Something is wrong with instantiation of generic roles and typed attributes in Rakudo
# New Ticket Created by "Carl Mäsak"
# Please include the string: [perl #109880]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org:443/rt3/Ticket/Display.html?id=109880 >
nom: role Foo[::T] { has T @.a = [T] }; class Bar {}; say
Foo[Bar].new.a[0]
nom a17736: OUTPUT«Cannot type check against type variable T [...]
jnthn: what's up with this?
hm
nom: my $r = role Foo[::T] { has T @.a }; $r.HOW.attributes($r).perl.say
nom 5a2c7d: OUTPUT«Method 'mro' not found for invocant of
class 'Perl6::Metamodel::ParametricRoleHOW' [...]
...interesting.
nom: my $r = role Foo[::T] { has T @.a };
$r.HOW.attributes($r, :local).[0].type.HOW.archetypes.generic.say
nom 5a2c7d: OUTPUT«1»
Hm, that much is right then.
masak: Not sure without going for a deeper dig...some kind of
generic instantiation failure.
* masak submits rakudobug
[perl #57228] Instantiation an object last in a program fails in rakudo
# New Ticket Created by "Carl Mäsak"
# Please include the string: [perl #57228]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=57228 >
Whereas
$ perl6 -e 'class A {}; my A $a .= new; 1'
$ perl6 -e 'class A {}; my A $a = A.new; 1'
$ perl6 -e 'class A {}; my A $a = A.new(); 1'
all work fine,
$ perl6 -e 'class A {}; my A $a .= new'
$ perl6 -e 'class A {}; my A $a = A.new'
$ perl6 -e 'class A {}; my A $a = A.new()'
all produce the same error, namely
get_bool() not implemented in class 'A'
current instr.: 'parrot;PCT::HLLCompiler;command_line' pc 1311
(src/PCT/HLLCompiler.pir:711)
called from Sub 'parrot;Perl6::Compiler;main' pc 14518 (perl6.pir:172)
Moreover,
$ perl6 -e 'class A {}; my A $a = A.new(); 1'
works, but
perl6 -e 'class A; my A $a .= new'
Method 'ACCEPTS' not found for non-object
current instr.: '!DOTYPECHECK' pc 11697 (src/gen_builtins.pir:7467)
called from Sub 'parrot;Perl6Object;infix:=' pc 60 (src/gen_builtins.pir:52)
called from Sub 'parrot;A;_block21' pc 95 (EVAL_13:45)
called from Sub 'parrot;PCT::HLLCompiler;evalpmc' pc 744
(src/PCT/HLLCompiler.pir:448)
called from Sub 'parrot;PCT::HLLCompiler;compile' pc 438
(src/PCT/HLLCompiler.pir:303)
called from Sub 'parrot;PCT::HLLCompiler;eval' pc 776
(src/PCT/HLLCompiler.pir:473)
called from Sub 'parrot;PCT::HLLCompiler;command_line' pc 1305
(src/PCT/HLLCompiler.pir:708)
called from Sub 'parrot;Perl6::Compiler;main' pc 14518 (perl6.pir:172)
doesn't.
Re: [perl #41266] [PDD] object instantiation, new method
I like it. I have been thinking of suggesting the same thing.
Currently, hackery is used to get the new opcode to instantiate
objects. If classes become objects as well, the hackery breaks down.
Kevin
Allison Randal (via RT) wrote:
# New Ticket Created by Allison Randal
# Please include the string: [perl #41266]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=41266 >
Consider object instantiation as a method call on a class object, rather
than an opcode on a type ID.
$P0 = get_class "HLLClass"
$P1 = $P0.new()
Or even:
$P0 = get_hll_namespace
$P1 = $P0.find_class("HLLClass")
$P2 = $P1.new()
(Though the first could be shorthand for the second that assumes the
current selected namespace.)
Allison
[perl #41266] [PDD] object instantiation, new method
# New Ticket Created by Allison Randal
# Please include the string: [perl #41266]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=41266 >
Consider object instantiation as a method call on a class object, rather
than an opcode on a type ID.
$P0 = get_class "HLLClass"
$P1 = $P0.new()
Or even:
$P0 = get_hll_namespace
$P1 = $P0.find_class("HLLClass")
$P2 = $P1.new()
(Though the first could be shorthand for the second that assumes the
current selected namespace.)
Allison
Re: MakeObject - an Object Instantiation Experiment
Am Dienstag, 10. Oktober 2006 21:32 schrieb chromatic: > > new P0, [class], > > Is a PMC (Hash) or a list of named arguments? Creating a Hash for > every initializer is a real bummer in PIR. As said, ought to be everything conforming to current calling conventions. o = new .TypeId, 1, 'baz', 'x' => 'foo', 'y' => 42 or whatever - that's the plan(tm). leo
Re: MakeObject - an Object Instantiation Experiment
Am Dienstag, 10. Oktober 2006 20:41 schrieb chromatic: > Hi all, > > Here's an experiment I worked on yesterday to make creating objects a > little easier from PIR. For reference: Subject: PMC and object creation http://groups.google.de/group/perl.perl6.internals/browse_frm/thread/e68dc0a0a96585b7/462023a5939b0844?lnk=st&q=toetsch++new+opcodes&rnum=30#462023a5939b0844 PS: the examples are w/o syntactic sugar support for making the 'new/instantiate' thingy any nicer. It's just an experiment how it could work. The basics are: it combines all the flexible argument passing features we already have with object instantiation. PPS: new opcode variant count is 20 now. I can imagine that we just have these: new P0, .Class # plain form new P0, .Class, new P0, [class], leo
Re: MakeObject - an Object Instantiation Experiment
On Tuesday 10 October 2006 12:23, Leopold Toetsch wrote:
> PPS: new opcode variant count is 20 now.
>
> I can imagine that we just have these:
>
> new P0, .Class # plain form
> new P0, .Class,
> new P0, [class],
Is a PMC (Hash) or a list of named arguments? Creating a Hash for
every initializer is a real bummer in PIR.
(It makes me want to suggest that, just as [ class ] creates a Key PMC behind
the scenes, so { key => value } creates a Hash PMC.)
-- c
MakeObject - an Object Instantiation Experiment
Hi all, Here's an experiment I worked on yesterday to make creating objects a little easier from PIR. The MakeObject library allows you to create an object by passing its name (or, more usefully, a Key PMC) and a set of named arguments to the initializer. It then calls the class's BUILDALL() method, if it exists, or the BUILD() methods on each class, least-to-most-derived, passing the arguments. This surprisingly removes a lot of complexity in PIR objects. -- c === runtime/parrot/library/MakeObject.pir == --- runtime/parrot/library/MakeObject.pir (revision 22977) +++ runtime/parrot/library/MakeObject.pir (local) @@ -0,0 +1,87 @@ +.include "iterator.pasm" + +.namespace [ 'MakeObject' ] + +.sub make_object + .param pmc classname + .param pmc args :slurpy :named + + .local int obj_type + find_type obj_type, classname + + .local pmc obj + obj = new obj_type + + build_all( obj, args ) + .return( obj ) +.end + +.sub build_all + .param pmc obj + .param pmc args + + .local int can_ba + can_ba = can obj, 'BUILDALL' + + unless can_ba goto do_it_yourself + obj.'BUILDALL'( args ) + .return() + + do_it_yourself: + .local pmc class_pmc + class_pmc = class obj + + .local pmc mro + mro = get_mro class_pmc + + .local pmc iter + iter = new .Iterator, mro + set iter, .ITERATE_FROM_END + + .local pmc class_pmc + .local pmc class_ns + .local pmc build_meth + .local int has_build + iter_loop: + unless iter goto iter_end + class_pmc = pop iter + class_ns = get_class_namespace( class_pmc ) + build_meth = class_ns.'find_sub'( 'BUILD' ) + + has_build = defined build_meth + unless has_build goto iter_loop + + obj.build_meth( args ) + + goto iter_loop + + iter_end: + .return() +.end + +.sub get_class_namespace + .param pmc class_pmc + + .local pmc ns + ns = get_hll_namespace + + .local string class_name + class_name = typeof class_pmc + + .local pmc name_array + name_array = split ';', class_name + + .local pmc iter + iter = new .Iterator, name_array + iter = 0 + + .local pmc elem + iter_loop: + unless iter goto iter_end + elem = shift iter + ns = ns.find_namespace( elem ) + goto iter_loop + + iter_end: + .return( ns ) +.end === t/library/make_object.pir == --- t/library/make_object.pir (revision 22977) +++ t/library/make_object.pir (local) @@ -0,0 +1,83 @@ +.sub main :main + load_bytecode 'MakeObject.pir' + + build_classes() + + .local pmc make_object + make_object = find_global 'MakeObject', 'make_object' + + .local pmc gk_name + gk_name = new .Array + gk_name = 4 + gk_name[0] = 'Grandchild' + gk_name[1] = 'Happy' + gk_name[2] = 'Fun' + gk_name[3] = 'Class' + + .local pmc gk + gk = make_object( gk_name, 'foo' => 'bar', 'baz' => 'quux' ) +.end + +.sub build_classes + .local pmc parent + parent = newclass 'Parent' + + .local pmc kid_name + .local pmc key_item + kid_name = new .Key + kid_name = 'Child' + key_item = new .Key + key_item = 'Class' + push kid_name, key_item + + .local pmc child + child = subclass 'Parent', kid_name + + .local pmc gk_name + gk_name = new .Key + gk_name = 'Grandchild' + key_item = new .Key + key_item = 'Happy' + push gk_name, key_item + key_item = new .Key + key_item = 'Fun' + push gk_name, key_item + key_item = new .Key + key_item = 'Class' + push gk_name, key_item + + .local pmc grandchild + grandchild = subclass child, gk_name +.end + +.namespace [ 'Parent' ] + +.sub BUILD :method + .param pmc args :slurpy :named + .local pmc foo + foo = args['foo'] + args['baz'] = 'fzort' + print "Build in parent\n" + print "Foo: " + print foo + print "\n" +.end + +.namespace [ 'Child'; 'Class' ] + +.sub BUILD :method + .param pmc args :slurpy :named + print "Build in child\n" +.end + +.namespace [ 'Grandchild'; 'Happy'; 'Fun'; 'Class' ] + +.sub BUILD :method + .param pmc args :slurpy :named + .local pmc baz + baz = args['baz'] + print "Build in grandchild\n" + print "Baz: " + print baz + print "\n" +.end
Re: PMC instantiation
Dan Sugalski <[EMAIL PROTECTED]> wrote: > At 11:27 AM +0200 9/3/04, Leopold Toetsch wrote: >>Dan Sugalski <[EMAIL PROTECTED]> wrote: >>> At 12:16 PM +0200 8/31/04, Leopold Toetsch wrote: Pclass = getclass, "Foo" Pobjnew = Pclass."__new"(args) # Pnew is an OUT argument and that be special-cased to call VTABLE_new according to calling conventions. >> >>> Still don't like __new, but otherwise that works out OK. It'd call >>> VTABLE_init_extended or whatever we'd name the entry. >> >>Ok. It is actually "new_extended" now. It's creating new objects, so >>"init_extended" didn't totally match the behaviou?r. > Oh. This isn't right. The extended stuff's extended initialization, > just like init is now. It works on the PMC it's attached to, rather > than allocating a new PMC from the pool. I was always talking about a class method that returns new objects like in the example above. If we need extended initialization too, then that's a different set of opcode/vtable. The C matches nicely Python's object construction, like: c = complex(1,2) where "complex" actually is a class. leo
Re: PMC instantiation
At 11:27 AM +0200 9/3/04, Leopold Toetsch wrote: Dan Sugalski <[EMAIL PROTECTED]> wrote: At 12:16 PM +0200 8/31/04, Leopold Toetsch wrote: Pclass = getclass, "Foo" Pobjnew = Pclass."__new"(args) # Pnew is an OUT argument and that be special-cased to call VTABLE_new according to calling conventions. Still don't like __new, but otherwise that works out OK. It'd call VTABLE_init_extended or whatever we'd name the entry. Ok. It is actually "new_extended" now. It's creating new objects, so "init_extended" didn't totally match the behaviou?r. Oh. This isn't right. The extended stuff's extended initialization, just like init is now. It works on the PMC it's attached to, rather than allocating a new PMC from the pool. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: PMC instantiation
Dan Sugalski <[EMAIL PROTECTED]> wrote: > At 12:16 PM +0200 8/31/04, Leopold Toetsch wrote: >> >>Pclass = getclass, "Foo" >>Pobjnew = Pclass."__new"(args) # Pnew is an OUT argument >> >>and that be special-cased to call VTABLE_new according to calling >>conventions. > Still don't like __new, but otherwise that works out OK. It'd call > VTABLE_init_extended or whatever we'd name the entry. Ok. It is actually "new_extended" now. It's creating new objects, so "init_extended" didn't totally match the behaviou?r. Initial tests are in as well as a fallback in default.pmc that constructs a new PMC without initializers. leo
Re: PMC instantiation
At 12:16 PM +0200 8/31/04, Leopold Toetsch wrote: Dan Sugalski <[EMAIL PROTECTED]> wrote: Add a vtable slot to the PMC vtable inv_init (or something like that, the name's not that big a deal), vtable->new and "__new"? Those are a little too similarly named. We should have something more distinct, I think. > ... define it as an invokable method taking parameters as the current calling conventions, and be done with it. Basically we special-case this one method and hoist it up into a vtable slot. IMCC for it'd look something like: (result1, result2) = $Pxxx.inv_init(1, 2, "foo", "bar", $Pbaz) Two return values? What is $Pxxx: a class PMC or an empty Undef object of some kind? $Pxxx is an uninitialized object of the class you're creating, but that won't work at the PIR level. PIR combines the new and init functions together, which I always forget. I think we should have: Pclass = getclass, "Foo" Pobjnew = Pclass."__new"(args) # Pnew is an OUT argument and that be special-cased to call VTABLE_new according to calling conventions. Still don't like __new, but otherwise that works out OK. It'd call VTABLE_init_extended or whatever we'd name the entry. How does that correspond to the proposed CONSTRUCT property? Is that still needed? I don't think CONSTRUCT would be needed with this. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: PMC instantiation
Dan Sugalski <[EMAIL PROTECTED]> wrote: > Add a vtable slot to the PMC vtable inv_init (or something like that, > the name's not that big a deal), vtable->new and "__new"? > ... define it as an invokable method > taking parameters as the current calling conventions, and be done > with it. Basically we special-case this one method and hoist it up > into a vtable slot. IMCC for it'd look something like: > (result1, result2) = $Pxxx.inv_init(1, 2, "foo", "bar", $Pbaz) Two return values? What is $Pxxx: a class PMC or an empty Undef object of some kind? I think we should have: Pclass = getclass, "Foo" Pobjnew = Pclass."__new"(args) # Pnew is an OUT argument and that be special-cased to call VTABLE_new according to calling conventions. How does that correspond to the proposed CONSTRUCT property? Is that still needed? leo
PMC instantiation
The current scheme of PMC instantiation works mostly fine for scalars and other simple types, but it's a bit limited. It allows only one initializer (see init_pmc in docs/pdds/pdd02_vtables.pod). Further PMC and "real object" instantiation shouldn't differ in syntax. Here is a summary what we currently have: .sub main @MAIN $P0 = new Integer # known type $P1 = new Ref, $P0 # same with initializer $I0 = find_type "Integer" $P1 = new $I0 # dynamic type or object .local NCI clas clas = global "Py_int" # with parrot --python foo.imc $P0 = "0x2a" $P2 = clas($P0) # the pythonic way clas = getclass "PerlInt" # similar to getting the global .local NCI newf newf = global "__new__" $P0 = "0x2a" $P2 = newf(clas, $P0) # the "new" pythonic way .end Perl6 seems to favor a scheme similar to the last one, something like: $P2 = clas."new"($P0) Python classes and types also have a "__new__" property, so that both schemes end up as the same, namely as a class method. Anyway the advantage of the latter two methods is obviously that the constructors can take arbitrary initializer arguments like any other function call. Finally we must be able to override the instantiation. Parrot seems to have the "CONSTRUCT" property for that[1]. But I can imagine that a C vtable [2] would work as well. Comments welcome, leo [1] if that's supposed to do instantiation, the code in objects.c is bogus. [2] see e.g. invoke() in classes/perlint.pmc
Re: Instantiation
[EMAIL PROTECTED] (Aaron Sherman) writes:
> > my $x = Some::Module::That::Defines::A::Class.AUTOLOAD.new("blah");
>
> Wow, that's pretty amazing... uh... I think I'd just prefer to do it
> the old fashioned way. If my suggestion was really that horrific, I
> withdraw the question.
These days, to me, the old fashioned way is just a variation on
UNIVERSAL::require. ;)
Foo->require->new # UNIVERSAL::require doesn't return "Foo", but it (c|sh)ould.
--
Sucks really Forth. Ugh.
Re: Instantiation
Dave Whipp wrote:
"Sean O'Rourke" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
my $x = (use Some::Module::That::Defines::A::Class).new("blah");
how about some variation on
my $x = Some::Module::That::Defines::A::Class.AUTOLOAD.new("blah");
Wow, that's pretty amazing... uh... I think I'd just prefer to do it
the old fashioned way. If my suggestion was really that horrific, I
withdraw the question.
Re: Instantiation
"Sean O'Rourke" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> my $x = (use Some::Module::That::Defines::A::Class).new("blah");
how about some variation on
my $x = Some::Module::That::Defines::A::Class.AUTOLOAD.new("blah");
Dave.
Re: Instantiation
At Mon, 23 Aug 2004 15:51:00 -0400,
[EMAIL PROTECTED] (Aaron Sherman) wrote:
>
> On Mon, 2004-08-23 at 15:19, Paul Seamons wrote:
> > > So, I was wondering about a synonym, like:
> > >
> > > uses Some::Module::That::Defines::A::Class $foo;
> >
> > Well if the long name is the problem:
> >
> > use Some::Module::That::Defines::A::Class as Foo;
>
> No, like I said: this is not golf. I'm trying to remove an element of
> redundancy that I think obscures the meaning of a set of statements.
>
> Saying,
>
> use reallylongnameforamodulethathassomeclass as Foo;
> our Foo $bar := .new;
>
> Still has the same redundancy, it's just been hidden a bit. If
> "use/instantiate" is a common practice for certain kinds of library,
> then I think we should have a mechanism to perform that pair as a single
> step.
How about making "use" a list operator returning the module's return
value (== its last statement?)? Then you could do something like
my $x = (use Some::Module::That::Defines::A::Class).new("blah");
This leaves a bad taste in my mouth -- I think importing a module and
instantiating its main class should remain separate -- but this looks
like a painless way to get what you want without a separate function
or keyword.
/s
Re: Instantiation
Hello, Aaron Sherman wrote: > I was thinking about the case where you use a module, only to define a > class that you then instantiate like this: [ snip ] > So, I was wondering about a synonym, like: > > uses Some::Module::That::Defines::A::Class $foo; is $foo implicitely declared as our or my (or state or temp)? IMHO it'd be better to be explicit: my $foo = uses Some::Module::That::Defines::A::Class; our $bar = uses Some::Module::That::Defines::A::Class; Or, requiring C to return it's first argument (IIRC a Class object): my $qux = use(Some::Module::That::Defines::A::Class).new(...); If C's argument is a Module object, C should return the first class of that module. I like the C form the best, because it allows you to pass parameters to C. Ingo Blechschmidt -- Linux, the choice of a GNU | Running Windows on a Pentium is like having generation on a dual AMD- | a brand new Porsche but only be able to Athlon!| drive backwards with the handbrake on. Encrypted mails preferred. | (Unknown source)
Re: Instantiation
Aaron Sherman wrote:
I was thinking about the case where you use a module, only to define a
class that you then instantiate like this:
use Some::Module::That::Defines::A::Class;
our Some::Module::That::Defines::A::Class $foo := new;
and I keep thinking that that's too redundant. It's not so much that I
want to syntax-golf it down, but there's just no reason to throw that
type around twice, when what you really WANT to say is "that module over
there is a class, instantiate me one."
So, I was wondering about a synonym, like:
uses Some::Module::That::Defines::A::Class $foo;
syntax will be awful and there are a lot of guesses, but:
macro uses($class, $var) is parsed(/() ()/) {
use $class;
our $class $var;
}
I suspect. It's probably not quite that simple, but I figured it was
worth a shot. Hopefully the compiler would run through the result of the
macro, parse it and compile it as normal so the C would actually work.
Okay okay, I just got a copy of Perl 6 and Parrot Essentials and I'm
trying to learn stuff. I'm even ripping apart the compiler I wrote for
my BSc final-year project so it generates working PIR instead of broken C.
Re: Instantiation
On Mon, Aug 23, 2004 at 12:53:04PM -0400, Aaron Sherman wrote: > I was thinking about the case where you use a module, only to define a > class that you then instantiate like this: > > use Some::Module::That::Defines::A::Class; > our Some::Module::That::Defines::A::Class $foo := new; > > and I keep thinking that that's too redundant. It's not so much that I > want to syntax-golf it down, but there's just no reason to throw that > type around twice, when what you really WANT to say is "that module over > there is a class, instantiate me one." > > So, I was wondering about a synonym, like: > > uses Some::Module::That::Defines::A::Class $foo; How about this? my :autouse Some::Module::That::Defines::A::Class $foo; -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: Instantiation
On Mon, 2004-08-23 at 15:19, Paul Seamons wrote: > > So, I was wondering about a synonym, like: > > > > uses Some::Module::That::Defines::A::Class $foo; > > Well if the long name is the problem: > > use Some::Module::That::Defines::A::Class as Foo; No, like I said: this is not golf. I'm trying to remove an element of redundancy that I think obscures the meaning of a set of statements. Saying, use reallylongnameforamodulethathassomeclass as Foo; our Foo $bar := .new; Still has the same redundancy, it's just been hidden a bit. If "use/instantiate" is a common practice for certain kinds of library, then I think we should have a mechanism to perform that pair as a single step. As for the previous suggestion from Juerd... I don't think that autoloading classes is quite the same. First, I'm not sure how that behaves in a pre-compiled environment. When does the autoload happen? Next, it's not explicit, and can thus lead to mistakes. With "uses", the module inclusion is explicit, it just also happens to be an instantiater. -- â 781-324-3772 â [EMAIL PROTECTED] â http://www.ajs.com/~ajs
Re: Instantiation
> So, I was wondering about a synonym, like: > > uses Some::Module::That::Defines::A::Class $foo; Well if the long name is the problem: use Some::Module::That::Defines::A::Class as Foo; my Foo $obj .= new; # OR # require Some::Module::That::Defines::A::Class; import Some::Module::That::Defines::A::Class as Foo; This seems to be more similar to what is done in other languages. You still have to write the class name repeatedly - but it does cut the typing. It does reduce the magic that is occuring behind the scenes (or at least redirects it to somewhere else). I guess Foo would be a full fledged class which inherits from Some::Module::That::Defines::A::Class. I doubt that it is optimal - but it does give a little bit of flexibility. Paul Seamons
Re: Instantiation
Aaron Sherman skribis 2004-08-23 12:53 (-0400): > use Some::Module::That::Defines::A::Class; > our Some::Module::That::Defines::A::Class $foo := new; > and I keep thinking that that's too redundant > (...) > So, I was wondering about a synonym, like: > uses Some::Module::That::Defines::A::Class $foo; Maybe, but I'd like something like this better: #!/usr/bin/perl6 use Module::AutoLoader :except(rx/^ Baz\:\: /); my Foo::Bar$bar .= new; my Quux::Xyzzy $xyzzy .= new; my Baz::Blah $blah .= new; # error, because there is no Baz::Blah::new Perhaps something must be added to tell it *when* to load modules: at runtime or during compilation. It shouldn't be hard to implement this module yourself, should it not go into the standard distribution. Juerd
Instantiation
I was thinking about the case where you use a module, only to define a
class that you then instantiate like this:
use Some::Module::That::Defines::A::Class;
our Some::Module::That::Defines::A::Class $foo := new;
and I keep thinking that that's too redundant. It's not so much that I
want to syntax-golf it down, but there's just no reason to throw that
type around twice, when what you really WANT to say is "that module over
there is a class, instantiate me one."
So, I was wondering about a synonym, like:
uses Some::Module::That::Defines::A::Class $foo;
This would be handy to have for those lengthy setups of all of the
objects you have to have lying around:
uses CGI $cgi :threaded :persistent;
uses Apache $server;
uses MLDBM $shared_data :file('/var/www/cache/cgi-shared-data');
uses IO::CGI $input :cgi($cgi);
uses MIME::Entity $message :input($input);
...etc...
--
â 781-324-3772
â [EMAIL PROTECTED]
â http://www.ajs.com/~ajs
Re: Object instantiation
On Oct 21, 2003, at 7:14 AM, Dan Sugalski wrote: After thinking about this a bit, it became glaringly obvious that the right way to instantiate an object for class "Foo" is to do: new P5, .Foo Or whatever the constant value assigned to the Foo class upon its creation is. When a class is created, it should be assigned a number, and for most things PMC-only classes or full-on HLL classes should behave identically. Duh. That makes sense. What I keep wondering is what about things with the semantics of Perl5, in which new objects aren't instantiated directly--already-allocated things later become associated with a class. This doesn't seem quite like a case of morphing, since for instance a Perl array can be blessed into a class, but it's still a Perl array. JEff
Re: Object instantiation
Try: new P0, 'std::array' # PMC new P1, 'Perl::PerlArray'# PMC (or class) new P2, 'Package::SomeClass' # Class At compile time the string can be converted to an integer enumerator. -Melvin Leopold Toetsch <[EMAIL PROTECTED]> 10/21/2003 10:24 AM Please respond to lt To: [EMAIL PROTECTED] (Dan Sugalski) cc: [EMAIL PROTECTED] Subject:Re: Object instantiation Dan Sugalski <[EMAIL PROTECTED]> wrote: > After thinking about this a bit, it became glaringly obvious that the > right way to instantiate an object for class "Foo" is to do: > new P5, .Foo > Or whatever the constant value assigned to the Foo class upon its creation > is. When a class is created, it should be assigned a number, and for most > things PMC-only classes or full-on HLL classes should behave identically. Yep. The question does arise, if which range class enums are? Intermixed with enum_class_ numbers? And - what about: typeof S0, P0 <=> classname S0, P0 (IMHO the HLL compiler can't always know, which op to use) And the classname of objects vs the classname of classes (the classname PMC is in different array slots). > Dan leo
Re: Object instantiation
On Tue, 21 Oct 2003, Leopold Toetsch wrote: > Dan Sugalski <[EMAIL PROTECTED]> wrote: > > After thinking about this a bit, it became glaringly obvious that the > > right way to instantiate an object for class "Foo" is to do: > > > new P5, .Foo > > > Or whatever the constant value assigned to the Foo class upon its creation > > is. When a class is created, it should be assigned a number, and for most > > things PMC-only classes or full-on HLL classes should behave identically. > > Yep. The question does arise, if which range class enums are? Intermixed > with enum_class_ numbers? Yes, intermixed. I added support a while back to pass in the class number to a PMC class being initialized for this very reason. The compiled-in PMCs get fixed numbers at the beginning because it's easiest, and things get referenced symbolically from there. > And - what about: > > typeof S0, P0 <=> classname S0, P0 > > (IMHO the HLL compiler can't always know, which op to use) At this point they're the same thing, I think. I'll need to think on it a bit. > And the classname of objects vs the classname of classes (the classname > PMC is in different array slots). Last I knew there was something of a fight over what class a class is in. At the moment I'm going to ignore the heck out of things and let the language folks fight over it some more. Dan
Re: Object instantiation
Dan Sugalski <[EMAIL PROTECTED]> wrote: > After thinking about this a bit, it became glaringly obvious that the > right way to instantiate an object for class "Foo" is to do: > new P5, .Foo > Or whatever the constant value assigned to the Foo class upon its creation > is. When a class is created, it should be assigned a number, and for most > things PMC-only classes or full-on HLL classes should behave identically. Yep. The question does arise, if which range class enums are? Intermixed with enum_class_ numbers? And - what about: typeof S0, P0 <=> classname S0, P0 (IMHO the HLL compiler can't always know, which op to use) And the classname of objects vs the classname of classes (the classname PMC is in different array slots). > Dan leo
Object instantiation
After thinking about this a bit, it became glaringly obvious that the right way to instantiate an object for class "Foo" is to do: new P5, .Foo Or whatever the constant value assigned to the Foo class upon its creation is. When a class is created, it should be assigned a number, and for most things PMC-only classes or full-on HLL classes should behave identically. Duh. One more thing down--now to actually make it work out... Dan
Re: Class instantiation and creation
If memory serves me right, Dan Sugalski wrote: > It's possible to just go ahead and do it *all* at runtime, and have > no compile time component at all--just a series of "newclass, > addparent, addattribute" ops, assuming those are the op names we go > with. Classes just get created at code initialization time or > something. That would be cool .. a lot easier to debug this kind of thing , especially when you could dump it as imcc and have it constant evaluated as a bytecode segment (wishful thinking ;) Question #1 : Are classes allowed to have fields ? Question #2 : Visibility ? Question #3 : Static methods ? Question #4 : Static constructors ? Question #5 : Destructor semantics .. Questions #3 & #4 can be emulated and #2 is only optional but #1 & #5 are of concern .. > instantiate a new class you need a chunk of bytecode around. It's > possible that at least some of this is only doable with metadata in > bytecode, but the bytecode metadata segments can be easily created on > the fly. Hmm... like compile some imcc on the fly ? > Anyone got any feelings or opinions on this, besides "Why yes, I want > an object system"? :) Class-based info I may be missing would also be > welcome. "Why who wouldn't ?" How would the override of a method happen ? ... would it be purely by name or would you provide some way to force a method to override another of a different name ? .. Ie add a method forcibly over an occupied slot ?. Gopal -- The difference between insanity and genius is measured by success
Re: Class instantiation and creation
Dan Sugalski wrote: The issue is metadata. How do you declare a class' inheritance hierarchy, its interfaces, its attributes, and its type? (At the very least, there's probably more) I can see the following . 1) A class subclasses a single parent. 2) A class subclasses a single parent and adds attributes 3) A class subclasses multiple parents 4) A class subclasses multiple parents with extra attributes 5) A class adds attributes at runtime 6) A class adds parents at runtime How about removing parents or attributes at runtime? Matt
Re: Class instantiation and creation
Dan Sugalski wrote: Well, we can make objects and we can call methods on objects (at least the interface is specified, if not actually implemented) but actually building classes to make objects out of is still unspecified. So, time to remedy that, after which I hope we can build at least a simple "ParrotObject" class. The issue is metadata. How do you declare a class' inheritance hierarchy, its interfaces, its attributes, and its type? (At the very least, there's probably more) I can see the following . 1) A class subclasses a single parent. 2) A class subclasses a single parent and adds attributes 3) A class subclasses multiple parents 4) A class subclasses multiple parents with extra attributes 5) A class adds attributes at runtime 6) A class adds parents at runtime Why not just have 1, 2 and 3 be degenerate cases 4? We're going to need to be able to do all these at runtime as well as load time, the question is how. It's possible to just go ahead and do it *all* at runtime, and have no compile time component at all--just a series of "newclass, addparent, addattribute" ops, assuming those are the op names we go with. Classes just get created at code initialization time or something. Would "adparent" replacate the metadata of the parent into the metadata of the child or will we need to walk the inheritence tree to get the metadata about inherited attributes? Part of me wants to go all-metadata for cases 2, 3, and 4, since I'm wary of the issues of doing what should be an atomic action in multiple ops. There's a loss of atomicity at the program level there, and if the classes override some of the actions (if we even allow that--does anyone allow overloading the subclassing operation?) it could get messy. #5 really has to be metadata based, as it'll be expensive as it is. Refiguring the attribute array is a constant-time operation, more or less, so doing it 6 times to add in 6 attributes seems... suboptimal. If we don't do it with metadata we'll need ops that allow adding in multiple elements in one go. Another possibility is to have an "addslots N" op to pre-extend the class and only dynamically extend if necessary. -- [EMAIL PROTECTED] [EMAIL PROTECTED]
Class instantiation and creation
Well, we can make objects and we can call methods on objects (at least the interface is specified, if not actually implemented) but actually building classes to make objects out of is still unspecified. So, time to remedy that, after which I hope we can build at least a simple "ParrotObject" class. The issue is metadata. How do you declare a class' inheritance hierarchy, its interfaces, its attributes, and its type? (At the very least, there's probably more) I can see the following . 1) A class subclasses a single parent. 2) A class subclasses a single parent and adds attributes 3) A class subclasses multiple parents 4) A class subclasses multiple parents with extra attributes 5) A class adds attributes at runtime 6) A class adds parents at runtime I'm not too worried about adding interfaces at runtime, as that doesn't do anything more, really, than adding methods at runtime. Either way's fine, it's just a bit of extra provided metadata that's only there when you query it. We're going to need to be able to do all these at runtime as well as load time, the question is how. It's possible to just go ahead and do it *all* at runtime, and have no compile time component at all--just a series of "newclass, addparent, addattribute" ops, assuming those are the op names we go with. Classes just get created at code initialization time or something. It's also possible that, except for case #1, all these things can only be done at compile time. (Which rules out 5 and 6) Classes are declared exclusively with some sort of bytecode metadata and to instantiate a new class you need a chunk of bytecode around. It's possible that at least some of this is only doable with metadata in bytecode, but the bytecode metadata segments can be easily created on the fly. Case #1 will definitely want to be doable with a single op, at runtime. It's a reasonably common operation, as these things go, as folks make anonymous child classes for single objects. I know there are good reasons to be able to do that both from a user program standpoint as well as for internal reasons. (Mainly to allow per-object method overriding without having to go through too many hoops) Part of me wants to go all-metadata for cases 2, 3, and 4, since I'm wary of the issues of doing what should be an atomic action in multiple ops. There's a loss of atomicity at the program level there, and if the classes override some of the actions (if we even allow that--does anyone allow overloading the subclassing operation?) it could get messy. #5 really has to be metadata based, as it'll be expensive as it is. Refiguring the attribute array is a constant-time operation, more or less, so doing it 6 times to add in 6 attributes seems... suboptimal. If we don't do it with metadata we'll need ops that allow adding in multiple elements in one go. #6, well... I'm not sure we should even allow #6, at least as part of the base parrot object system, but since we're going to do it anyway, we might as well do it right. The big issue with #6 being the same as #5--potentially needing to add in multiple attributes. That argues for a metadata approach, though alterations using metadata are dodgy. Anyone got any feelings or opinions on this, besides "Why yes, I want an object system"? :) Class-based info I may be missing would also be welcome. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Object Instantiation
On Fri, 11 Oct 2002 14:05:30 -0700, Michael Lazzaro wrote: > Maybe postfix ! on a class name means to autoinstantiate an object of > the named class only if/when first accessed: > > our FancyCache $cache; # declare, but leave undef > our FancyCache! $cache; # undef, but new() it if/when we need >it > our $cache returns FancyCache!; # the same > > (That's just a joke. Um, I think. Hmm...) Apart from the "auto" bit of "autoinstantiate", that's almost what it means in Eiffel, except there it's a prefix !! operator. Actually, you can specify a subclass between the two shrieks, but perl lets you do that by sticking Class:: on the method name, which means we'd only need one shriek: # ! is the new .= our FancyCache $cache; # declare but leave undef our FancyCache $cache ! new; # create new instance our FancyCache $cache ! ReallyFancyCache::new; # create subclass instance Eiffel does let you omit the name of the constructor if there is a single argumentless constructor, but Eiffel constructors are all marked as such, which (at least so far) Perl6 constructors aren't. -- Peter Haworth [EMAIL PROTECTED] "The Hotmail migration is becoming the IT equivalent of painting-the-Forth- bridge, evidently. Once you've think you've finished migrating one end, more FreeBSD boxes reappear at the other. So you have to start all over again." -- http://www.theregister.co.uk/content/28/23348.html
Re: Object Instantiation
On Thursday, October 10, 2002, at 05:11 PM, Larry Wall wrote: my MyClass $obj = .new; my new MyClass $obj; Thanks for the clarification. I like those two OK, personally. If I were chained to one of those, I wouldn't chew my leg off. Tying it together with the other thread to make people *really* scream: On Tue, Oct 08, 2002 at 06:07:09PM -0700, Larry Wall wrote: I've always wondered what the ! postfix operator means. The mathematicians think they know. :-) Maybe postfix ! on a class name means to autoinstantiate an object of the named class only if/when first accessed: our FancyCache $cache; # declare, but leave undef our FancyCache! $cache; # undef, but new() it if/when we need it our $cache returns FancyCache!; # the same (That's just a joke. Um, I think. Hmm...) :-) :-) :-) MikeL
Re: Object Instantiation (Was: Re: [ANNOUNCE] Perl6 OO Cookbook, v0.1)
On Thu, 10 Oct 2002, Michael Lazzaro wrote:
: On Thursday, October 10, 2002, at 11:23 AM, John Williams wrote:
: > my $obj = MyClass(...);
: >
: > This seems to assume that objects have a default method if you treat
: > them
: > like a subroutine. Kinda tcl-ish, but I don't recall anything like
: > this
: > in the apocalypes.
: >
: > my $obj = MyClass;
: >
: > I think $obj would contain a reference to MyClass, not an instance
: > of MyClass.
:
: This is an area that's been bothering me for a while now (the Apoc's so
: far don't directly address it, AFAIK.) Here's why:
:
: Instantiating new objects is *darn* frequent in OO programming. And of
: those objects, a sizable number -- possibly even a majority -- have
: constructors with no required arguments, e.g. "default constructors".
: And pretty much every one of those constructors is going to be named
: ".new".
That's why it's short. :-)
: Therefore, since creating an object using a default constructor is
: really common, it should be drop-dead simple. I think there's utility
: in trying to accommodate:
:
: $obj = MyClass.new(...);# normal case
: $obj = MyClass.new; # if the constructor takes no args
: $obj = MyClass(...) # implied "new" w/ args
: $obj = MyClass; # implied "new", no args
:
: Since instantiating a class is MUCH more common than is passing classes
: themselves around, the latter case could be "expanded" instead:
:
: $obj = MyClass; # instantiate it, using the default constructor
: $obj = MyClass.TYPE;# assign a reference to MyClass
: $obj = 'MyClass'; # ... or just treat it as a string?
:
: trading less code in the very common case for more code in the
: not-as-common case. (It would make other things simpler, too, e.g.
: transformations.) So tho I have no say in the decision, I'm REALLY
: hoping that we can leave out the new().
Sorry, no. The bare class name will refer to the class itself in such
constructs as
when Dog { bark() }
when Cat { meow() }
if $! =~ IntegerOverflow {...}
&squeek := Mouse sub ($x) { return mickey($x) }
: (The idea of being able to drop the new() was stolen from languages in
: which the name of the constructor is the same as the name of the class,
: there is no new() at all.)
Yep, I know about those. Can't say I wasn't tempted. But the simpler
concept should generally have the simpler usage, I think, all other things
being equal. If you're going to do something verbish with a noun, there
ought to be a verb.
That being said, () is a verb of sorts, so we could allow a constructor
syntax in which a class functions as a subroutine reference. But that'd
probably be a shorthand for .new(), or whatever the conversion method is
called, where conversion from undef is equivalent to an argumentless .new().
: As far as the syntax for type declarations: I have less bees about
: this one. Clearly,
:
: my $obj is MyClass;
:
: should declare a variable of type MyClass. (You're right, it shouldn't
: autoviv.) So what's the simplest syntax for typing + instantiation,
: together? Dunno, maybe
:
: my $obj is MyClass .= new;
:
: is it, but still I'm hoping for an alternative that is easier to
: explain to people when I'm training them. Hmm, think, think...
Note that according to the current design team notions your syntax there
is declaring the type of the variable (like a tie), not the type of
the value. You want either
my MyClass $obj;
or
my $obj returns MyClass;
for that. (The first is just synactic sugar for the second.) Things get
more complicated for arrays and hashes. The following are equivalent:
my MyClass @array;
my @array returns MyClass;
my @array is Array of MyClass;
Or something like that.
How the constructor syntax will fit in with that is still up in
the air. I'm rather partial to tacking a closure on the end like
sub syntax, only the closure executes immediately at elaboration
time with the topic being the current object. But that may be the
general syntax rather than the usual syntax. Possibly a declaration
can serve as a topicalizer for any assignment or binding to itself,
so maybe you could say
my MyClass $obj = .new;
to mean the same as
my MyClass $obj { .new }
or maybe
my MyClass $obj { .init }
Or maybe we can have something weird like
my MyClass.new $obj;
That would assume that the object you're creating functions as its
own class. Except you don't actually have the object at compile time...
Perhaps one of
my new MyClass $obj;
new my MyClass $obj;
new MyClass my $obj;
my MyClass $obj is init;
my MyClass $obj.init;
could also be allowed for an argumentless form, though. But this is
all wild speculation at this point.
Larry
Object Instantiation (Was: Re: [ANNOUNCE] Perl6 OO Cookbook, v0.1)
On Thursday, October 10, 2002, at 11:23 AM, John Williams wrote: > my $obj = MyClass(...); > > This seems to assume that objects have a default method if you treat > them > like a subroutine. Kinda tcl-ish, but I don't recall anything like > this > in the apocalypes. > > my $obj = MyClass; > > I think $obj would contain a reference to MyClass, not an instance > of MyClass. This is an area that's been bothering me for a while now (the Apoc's so far don't directly address it, AFAIK.) Here's why: Instantiating new objects is *darn* frequent in OO programming. And of those objects, a sizable number -- possibly even a majority -- have constructors with no required arguments, e.g. "default constructors". And pretty much every one of those constructors is going to be named ".new". Therefore, since creating an object using a default constructor is really common, it should be drop-dead simple. I think there's utility in trying to accommodate: $obj = MyClass.new(...);# normal case $obj = MyClass.new; # if the constructor takes no args $obj = MyClass(...) # implied "new" w/ args $obj = MyClass; # implied "new", no args Since instantiating a class is MUCH more common than is passing classes themselves around, the latter case could be "expanded" instead: $obj = MyClass; # instantiate it, using the default constructor $obj = MyClass.TYPE;# assign a reference to MyClass $obj = 'MyClass'; # ... or just treat it as a string? trading less code in the very common case for more code in the not-as-common case. (It would make other things simpler, too, e.g. transformations.) So tho I have no say in the decision, I'm REALLY hoping that we can leave out the new(). (The idea of being able to drop the new() was stolen from languages in which the name of the constructor is the same as the name of the class, there is no new() at all.) As far as the syntax for type declarations: I have less bees about this one. Clearly, my $obj is MyClass; should declare a variable of type MyClass. (You're right, it shouldn't autoviv.) So what's the simplest syntax for typing + instantiation, together? Dunno, maybe my $obj is MyClass .= new; is it, but still I'm hoping for an alternative that is easier to explain to people when I'm training them. Hmm, think, think... MikeL
