__find_method Overrideable From PASM/PIR?

[chromatic]

According to PDD15, defining a method called __find_method() in my PASM
or PIR would allow Perl 5 AUTOLOAD-like behavior.

I can override __get_string() -- and it's tested in t/pmc/delegate.t. 
Is __find_method() workable yet?  If not, how would I go about adding
it?

t/pmc/delegate.t looks like the right place for it, but I distrust that,
for example, the test for __get_string() actually tests what it should
test.  I'd expect to need to define an entirely new class.

Of course, if I'm misunderstanding PDD15 altogether, that's cool too.

-- c

[DOCS] Ops parsing

[Michael Scott]

I've updated the docs for the ops parsing system.

	make html-clean; make html

You'll find it under Perl Modules/Operations and Ops/Tools.

Mike

Re: "new" method

[chromatic]

On Sun, 2004-04-04 at 10:17, Leopold Toetsch wrote:

> .sub __init method
> 
> is AFAIK the constructor. It gets called automatically for all parent
> classes and the class itself and is the best place to put attributes for
> objects in place and set these to their default values.

I personally want to pass arguments to the initializer ("constructor"
really isn't the right term).  I expect HLLs will want to do the same.

If we set a convention that the initializer is always called BUILD or
CREAT(E), that's fine.  I'd like to set or follow a wise convention now.

-- c

Re: "new" method

[Uri Guttman]

> "C" == Chris  <[EMAIL PROTECTED]> writes:

  C> How about some variation on "create"?

just please make sure it has the missing 'e'. :)

uri

-- 
Uri Guttman  --  [EMAIL PROTECTED]   http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs    http://jobs.perl.org

RE: "new" method

[Chris]

How about some variation on "create"?
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.593 / Virus Database: 376 - Release Date: 20/02/2004

Re: "new" method

[Leopold Toetsch]

Jens Rieks <[EMAIL PROTECTED]> wrote:
> Hi,

> Chromatic and I are unsure what the best name for a constructor method is.

.sub __init method

is AFAIK the constructor. It gets called automatically for all parent
classes and the class itself and is the best place to put attributes for
objects in place and set these to their default values.

> Leo, is it time-consuming to fix IMCC in order to make it possible to use
> "new" as a method name?

"new" isn't really easy to use. It's a Parrot op and second a keyword in
the lexer (which mightn't be really need anymore though).

> Is there something special to consider to avoid problems regarding several
> languages? Is BUILD a good name for a non Perl6 constructor method?

Well, constructors are class-namespace scoped anyway. So there shouldn't
be a problem.

> jens

leo

"new" method

[Jens Rieks]

Hi,

Chromatic and I are unsure what the best name for a constructor method is.

Leo, is it time-consuming to fix IMCC in order to make it possible to use 
"new" as a method name?

Is there something special to consider to avoid problems regarding several 
languages? Is BUILD a good name for a non Perl6 constructor method?

jens

Re: Languages testing

[Nicholas Clark]

On Sun, Mar 28, 2004 at 02:11:01AM -0500, Will Coleda wrote:

> use lib qw(../lib ../../lib ../../../lib);
> use Parrot::Config;
> my $path = $INC{"Parrot/Config.pm"};
> $path =~ s:lib/Parrot/Config.pm$::;
> 
> to figure out the path to the parrot executable.
> 
> Is this too evil, or should I go ahead and nuke Russia --- er, I mean, 
> submit my tcl patches, and then patches to the other languages to make 
> them do the same?

There is the danger that with an @INC like that you can pick up modules from
directories outside (ie immediately above) the parrot build tree.
Which can cause test failures.
(IIRC some of MakeMaker's tests can do this, and I've yet to supply schwern
with a patch)

Nicholas Clark

Language Interoperability

[Randy W. Sims]

On the Module-Build[1] mailing-list[2] we are currently discussing 
plugin architectures which will allow users to modify and extend 
Module::Build's functionality. One thing that we would like to have 
happen is that when the transition is made to parrot we'd like it to be 
possible to script Module::Build installs and write plugins in any of 
the languages supported by Parrot. In order to accomplish this we need 
to make sure that the plugin architecture chosen is compatible with any 
restrictions or limitations with regards to language interoperability.

For example, right now there are two prototypes for the plugin 
architecture. One[3] depends on inheritance, basically interjecting 
plugins into the class hierarchy and thus giving plugin authors access 
to modify and extend Module::Build's funtionality. The other[4] does not 
depend on inheritance; instead plugins must be installed into a certain 
directory structure where they can be found by Module::Build, and they 
must provide a compatible interface. These plugins require Module::Build 
to provide an API in order to modify or extend Module::Build's behaviour.

My concern is that restrictions in language interoperability may dictate 
certain design constraints, especially with regards to inheritance and 
runtime modification of the inheritance hierarchy, but also with regards 
to creating and manipulating objects across language boundaries. Another 
concern with the contract based architecture is that it generates 
methods within Module::Build at runtime that are intended to be 
overridable in subclasses of Module::Build.

Is there anything in the above that stands out as potentially being 
problematic?

Thanks,
Randy.
1. Module::Build is a replacement for MakeMaker.
   
2. Module-Build mailing-list on SourceForge:
   
3. Ken's inheritance based plugin architecture
   Subject: [Module::Build] Plugins
   Date: Thu, 1 Apr 2004 22:31:11 -0600
   
4. My contract based plugin architecture
   Subject: [Module::Build] [RFC] [PATCH] Action plugins
   Date: Sun, 30 Nov 2003 09:15:23 -0500
   

[CVS ci] diamond class hierarchy

[Leopold Toetsch]

Object gurus, please have a look at t/pmc/object-meths_17. Is the code 
ok? Is it failing because init order is really wrong?

BTW I tried to add this test as a TODO but this seems not to work.

leo