Creating a New Object (was Re: [TODO] Implement .loadlib pragma in IMCC)
On Wednesday 12 July 2006 11:27, Patrick R. Michaud wrote: The perl6 compiler has a custom string type, currently called Perl6Str. What's the canonically correct mechanism for creating an object of that type? $P0 = new 'Perl6Str' $P0 = new .Perl6Str $P0 = new [ 'Perl6Str' ] At different stages of Parrot development I've seen different answers to this question, so it'd be helpful to know what's correct. I tend to use: .local int str_type str_type = find_type [ 'Perl6Str' ] .local pmc p6str p6str= new str_type -- c
Re: Creating a New Object (was Re: [TODO] Implement .loadlib pragma in IMCC)
On Wed, Jul 12, 2006 at 11:36:56AM -0700, chromatic wrote: On Wednesday 12 July 2006 11:27, Patrick R. Michaud wrote: The perl6 compiler has a custom string type, currently called Perl6Str. What's the canonically correct mechanism for creating an object of that type? $P0 = new 'Perl6Str' $P0 = new .Perl6Str $P0 = new [ 'Perl6Str' ] I tend to use: .local int str_type str_type = find_type [ 'Perl6Str' ] .local pmc p6str p6str= new str_type Along similar lines... - If another HLL wants to create a Perl6Str, how does it do it? - If another HLL wants to create a subclass of Perl6Str...? Pm
Re: Creating a New Object (was Re: [TODO] Implement .loadlib pragma in IMCC)
On Wed, Jul 12, 2006 at 01:55:39PM -0500, Patrick R. Michaud wrote: On Wed, Jul 12, 2006 at 11:36:56AM -0700, chromatic wrote: On Wednesday 12 July 2006 11:27, Patrick R. Michaud wrote: The perl6 compiler has a custom string type, currently called Perl6Str. What's the canonically correct mechanism for creating an object of that type? $P0 = new 'Perl6Str' $P0 = new .Perl6Str $P0 = new [ 'Perl6Str' ] I tend to use: .local int str_type str_type = find_type [ 'Perl6Str' ] .local pmc p6str p6str= new str_type Along similar lines... - If another HLL wants to create a Perl6Str, how does it do it? - If another HLL wants to create a subclass of Perl6Str...? AFAIK there is no answer for this at present. (1) POSSIBLE KLUDGE In the very short term we could introduce a simple hack that would allow the user to specify the root namespace for the creation of the new class, defaulting to the HLL root: .HLL evillang .sub foo $P0 = get_hll_namespace# ['evillang'] $P1 = newclass ['Perl6Str'], $P0 # Not a Perl 6 string, but an incredible simulation ... (2) ELEGANT DIRECTION FOR THE FUTURE [to be determined] Seriously: Allison's busy (as am I) with nailing namespaces to the wall, so I wouldn't ask her to decide this. I do have ... not so much an idea, but an approach, which I'll suggest when the time comes: At present, newclass creates a class object and a namespace, both of which have the same name. That must change once we stop depending on typed namespaces. Assuming a single namespace object can represent a single class in future -- which is good for class manipulation and introspection -- I think we'd want to stop having 'newclass' futz with namespaces at all, leaving it up to the user to give it a name ... if any. Yes, Virginia, there are anonymous classes. :-) So it might look like: .HLL evillang .sub foo $P0 = newclass ... set_hll_global ['Perl6Str'], $P0 # Not a Perl 6 string, but an incredible simulation ... -- Chip Salzenberg [EMAIL PROTECTED]
Re: Creating a New Object (was Re: [TODO] Implement .loadlib pragma in IMCC)
On Wed, Jul 12, 2006 at 01:55:39PM -0500, Patrick R. Michaud wrote: On Wed, Jul 12, 2006 at 11:36:56AM -0700, chromatic wrote: On Wednesday 12 July 2006 11:27, Patrick R. Michaud wrote: $P0 = new 'Perl6Str' I tend to use: .local int str_type str_type = find_type [ 'Perl6Str' ] .local pmc p6str p6str= new str_type That's a rather complicated :-) way of expressing the one-liner above. Along similar lines... - If another HLL wants to create a Perl6Str, how does it do it? loadlib 'perl6' # or load_bytecode or whatever $P0 = new 'Perl6Str' - If another HLL wants to create a subclass of Perl6Str...? loadlib 'perl6' # or load_bytecode or whatever clas = subclass 'Perl6Str', 'MyStr' Pm leo
Re: Creating a New Object (was Re: [TODO] Implement .loadlib pragma in IMCC)
On Wed, Jul 12, 2006 at 12:15:07PM -0700, Chip Salzenberg wrote: - If another HLL wants to create a Perl6Str, how does it do it? - If another HLL wants to create a subclass of Perl6Str...? I just realized that I misinterpreted these questions. I thought that the first question was asking how some random HLL can create its own class that also has the name 'Perl6Str' -- i.e. a name collision question -- and that the second question was adding on by asking how the new name-collided class could coexist with (for example, derive from) the original. I'll be happy to answer the actual questions precisely, but I need to know more: Frst: Is this about now or the eventual future? Do you want the answer for when the full name of Perl6Str is ['parrot';'Perl6Str'], as I think it is today, or ['perl6';'Perl6Str'], as it should be eventually? Second: Does the derived class have to be named ['myhll','Perl6Str'], or can it have a new basename like ['myhll','MyPerl6Str']? AFAIK there is no answer for this at present. (1) POSSIBLE KLUDGE In the very short term we could introduce a simple hack that would allow the user to specify the root namespace for the creation of the new class, defaulting to the HLL root: .HLL evillang .sub foo $P0 = get_hll_namespace# ['evillang'] $P1 = newclass ['Perl6Str'], $P0 # Not a Perl 6 string, but an incredible simulation ... (2) ELEGANT DIRECTION FOR THE FUTURE [to be determined] Seriously: Allison's busy (as am I) with nailing namespaces to the wall, so I wouldn't ask her to decide this. I do have ... not so much an idea, but an approach, which I'll suggest when the time comes: At present, newclass creates a class object and a namespace, both of which have the same name. That must change once we stop depending on typed namespaces. Assuming a single namespace object can represent a single class in future -- which is good for class manipulation and introspection -- I think we'd want to stop having 'newclass' futz with namespaces at all, leaving it up to the user to give it a name ... if any. Yes, Virginia, there are anonymous classes. :-) So it might look like: .HLL evillang .sub foo $P0 = newclass ... set_hll_global ['Perl6Str'], $P0 # Not a Perl 6 string, but an incredible simulation ... -- Chip Salzenberg [EMAIL PROTECTED] -- Chip Salzenberg [EMAIL PROTECTED]
