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 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
