Jonathan Scott Duff writes:
> On Thu, Dec 04, 2003 at 05:57:52PM -0700, Luke Palmer wrote:
> > Hodges, Paul writes:
> > > I'd *like* to be able to predeclare a trait or property to be distributed
> > > across any values placed in this array, but only this array. For example, it
> > > would be nice
On Thu, Dec 04, 2003 at 05:57:52PM -0700, Luke Palmer wrote:
> Hodges, Paul writes:
> > I'd *like* to be able to predeclare a trait or property to be distributed
> > across any values placed in this array, but only this array. For example, it
> > would be nice if I could have the default aspects of
Paul Hodges writes:
> Luke Palmer:
> > Something likely more like:
> >
> > my role property_wrap[Property [EMAIL PROTECTED] {
> > method STORE($newval) { SUPER::STORE($newval but [EMAIL PROTECTED]) }
> > }
> > @bar but= property_wrap[false, foo];
>
> ...square brackets?
> ...r
--- Luke Palmer <[EMAIL PROTECTED]> wrote:
> Hodges, Paul writes:
> > How about
> >
> > use Baz; # assume object type
> > my property foo;
> > my @bar of Baz is false but foo; # maybe not what you meant?
>
> Definitely not what you meant. Fortunately, the compiler will teach
> you a thing
Hodges, Paul writes:
> How about
>
> use Baz; # assume object type
> my property foo;
> my @bar of Baz is false but foo; # maybe not what you meant?
Definitely not what you meant. Fortunately, the compiler will teach you
a thing or two about it: C is not a trait.
But indeed foo would a
How about
use Baz; # assume object type
my property foo;
my @bar of Baz is false but foo; # maybe not what you meant?
If you apply a trait like false to an array, I expect it to apply to the
"array instance object" itself and not the content, so that
push @bar, Baz.new();
if @bar{
--- Simon Cozens <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] (Paul Hodges) writes:
> > I am not seeing unicode.
>
> Don't worry because, and I honestly don't mean this disparagingly -
> by the time Perl 6 is ready for prime-time, you will. Larry got this
one
> right.
lol -- I think you're rig
[EMAIL PROTECTED] (Paul Hodges) writes:
> I am not seeing unicode.
Don't worry because, and I honestly don't mean this disparagingly - by the
time Perl 6 is ready for prime-time, you will. Larry got this one right.
--
"Jesus ate my mouse" or some similar banality.
-- Megahal (trained on
> And as far as I know, << and >> are exactly equivalent to æ?? and æ??
> in all cases.
lol I get the idea, but I foresee these unicode bits as becoming an
occasional sharp spot in my metaphorical seat of consciousness. :)
I am not seeing unicode.
__
Do you Y
--- Michael Lazzaro <[EMAIL PROTECTED]> wrote:
>
> On Monday, December 1, 2003, at 01:05 PM, Hodges, Paul wrote:
> > Didn't know "is" would do that. Good to know!
> > And in my meager defense, I did reference MikeL's operator
> > synopsis as of 3/25/03, which said ^[op] might be a synonym
> > for
On Tuesday, December 2, 2003, at 12:37 PM, Luke Palmer wrote:
Michael Lazzaro writes:
There were also vaguely threatening proposals to have <> and
>>op<<
do slightly different things. I assume that is also dead, and that
<> is (typically) a syntax error.
Ack. No, slightly different things would
Luke Palmer writes:
> And as far as I know, << and >> are exactly equivalent to æ and æ in all
> cases.
By which I mean  and Â, of course. :-/
(mutt is kind of a pain in this area)
Luke
Ã
Michael Lazzaro writes:
>
> On Monday, December 1, 2003, at 01:05 PM, Hodges, Paul wrote:
> >Didn't know "is" would do that. Good to know!
> >And in my meager defense, I did reference MikeL's operator synopsis as
> >of
> >3/25/03, which said ^[op] might be a synonym for <<>> or >><< (Sorry,
> >n
On Monday, December 1, 2003, at 01:05 PM, Hodges, Paul wrote:
Didn't know "is" would do that. Good to know!
And in my meager defense, I did reference MikeL's operator synopsis as
of
3/25/03, which said ^[op] might be a synonym for <<>> or >><< (Sorry,
no
fancy chars here. :)
Hey, that was *March*
> From: Luke Palmer [mailto:[EMAIL PROTECTED]
> Hodges, Paul writes:
> >
> > sub setvals ($o, [EMAIL PROTECTED]) {
> > $o but= $_;
> > $o.$_ = true;
> > }
>
> Y'all seem to be missing a C somewhere :-)
>
> sub setvals ($o, [EMAIL PROTECTED]) {
> $o bu
Hodges, Paul writes:
> I assume you're setting the the value, so I think I understand it, but
> how about
>
> sub setvals ($o, [EMAIL PROTECTED]) {
> $o but= $_;
> $o.$_ = true;
> }
>
> Though I'm still "iffy" about that $o.$_ business. I think
> $_(true) i
> From: Jonathan Scott Duff [mailto:[EMAIL PROTECTED]
> On Mon, Dec 01, 2003 at 10:42:09AM -0500, Hodges, Paul wrote:
> >
> > module IHL::Roles;
> > @ISA = 'Exporter';
> > @EXPORT_OK = qw/ fatal verbose allow setvals /;
> >
> > our role fatal is property {
> > has $.fatal is rw;
> >
On Mon, Dec 01, 2003 at 10:42:09AM -0500, Hodges, Paul wrote:
> So is this a good time to divert this topic into an elaboration of roles?
I can wait for A12, but in the mean time ... :-)
> So if I want to implement a package of related roles that I commonly use in
> our In-House code, such as to
--- Larry Wall <[EMAIL PROTECTED]> wrote:
> Well, it's not nearly as general as we're making it, but the
> inspiration for it comes in part from the "Traits" paper:
>
> http://www.cse.ogi.edu/~black/publications/TR_CSE_02-012.pdf
>
> Basically, I'm attempting to take their concept and unify
On Thursday, November 27, 2003, at 04:21 , Larry Wall wrote:
(Oh, apparently C# 2.0 is thinking along the same lines with its
"partial classes", though I haven't looked at those in detail.)
My reading was that C# 2's partial classes were merely a mechanism for
placing long method definitions in
Paul Hodges writes:
> Larry Wall writes:
> > Perl 5 didn't allow exportation of lexicals because typeglobs only
> > dealt with package variables, not lexical variables. In Perl 6
> > we'll be able to alias both lexicals and package variables. That
> > implies that a lexically scoped name can be e
With apologies, I'm already seeing blunders. *sigh*
> my Baz @ray = ( Baz.new() );
No reason to type that. Should be
my @ray = ( Baz.new() );
__
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
http://companion.yahoo.com/
> : And "exportation"???
>
> Exportation is just aliasing some name inside a scope to somewhere
> outside the scope. Importatation is the same operation from the
> viewpoint of the importing scope.
I just wasn't thinking clearly when you said it the first time.
> Perl 5 didn't allow exportation
> : but it confuses me. Does that mean you're leaning more toward
> : allowing undeclared properties, or just that you're still trying
> : to give both sides of the argument thorough consideration?
>
> I'm not doing either of those things... :-)
Yayy! :)
> : Just for my vote, I want to be able
On Sat, Nov 29, 2003 at 12:53:50PM -0800, Paul Hodges wrote:
:
: --- Larry Wall <[EMAIL PROTECTED]> wrote:
: > On Sat, Nov 29, 2003 at 08:50:57AM -0800, Paul Hodges wrote:
: > : hmm... lexical propertiesI've read the rest of the message,
: > : and I see how this could be a problem. Just to be
On Sat, Nov 29, 2003 at 12:40:10PM -0800, Paul Hodges wrote:
: --- Larry Wall <[EMAIL PROTECTED]> wrote:
: > Yes, in fact it gets a new anonymous class that is derived from its
: > current class.
:
: Ah -- implicit adoption by the new foster parent. That's kind of neat,
: but it confuses me. Does
--- Paul Hodges <[EMAIL PROTECTED]> wrote:
> print "foo" is $x;
With deeply sincere apologies, that should have been
print "foo" if $x;
__
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
http://companion.yahoo.com/
--- Larry Wall <[EMAIL PROTECTED]> wrote:
> On Sat, Nov 29, 2003 at 08:50:57AM -0800, Paul Hodges wrote:
> : hmm... lexical propertiesI've read the rest of the message,
> : and I see how this could be a problem. Just to be clear on it,
> : what exactly would it mean for a property or trait to
--- Larry Wall <[EMAIL PROTECTED]> wrote:
> On Sat, Nov 29, 2003 at 09:13:32AM -0800, Paul Hodges wrote:
> : --- Smylers <[EMAIL PROTECTED]> wrote:
> : > Larry Wall writes:
> : >
> : > > : if $x.foo { print "$x has property foo" }
> : > > : $x.bar = 1; # Or $x = $x but bar
> : > >
> :
On Sat, Nov 29, 2003 at 08:50:57AM -0800, Paul Hodges wrote:
: hmm... lexical propertiesI've read the rest of the message, and I
: see how this could be a problem. Just to be clear on it, what exactly
: would it mean for a property or trait to be lexical? If a value or
: container with that asp
On Sat, Nov 29, 2003 at 09:13:32AM -0800, Paul Hodges wrote:
: --- Smylers <[EMAIL PROTECTED]> wrote:
: > Larry Wall writes:
: >
: > > : if $x.foo { print "$x has property foo" }
: > > : $x.bar = 1; # Or $x = $x but bar
: > >
: > > Or maybe the .bar notation is only for rvalues, and to
--- Smylers <[EMAIL PROTECTED]> wrote:
> Larry Wall writes:
>
> > : if $x.foo { print "$x has property foo" }
> > : $x.bar = 1; # Or $x = $x but bar
> >
> > Or maybe the .bar notation is only for rvalues, and to create a
> > property you have to say:
> >
> > $x but= bar;
>
> I th
--- Larry Wall <[EMAIL PROTECTED]> wrote:
> On Thu, Nov 27, 2003 at 08:08:05PM -0800, Paul Hodges wrote:
> : --- Larry Wall <[EMAIL PROTECTED]> wrote:
> : > ... in fact, we may be limiting the creation of properties
> : > to predeclared names, so that even
> : >
> : > return 0 but ture;
> : >
Larry Wall writes:
> : if $x.foo { print "$x has property foo" }
> : $x.bar = 1; # Or $x = $x but bar
>
> Or maybe the .bar notation is only for rvalues, and to create a
> property you have to say:
>
> $x but= bar;
I think that would be an unPerlish restriction; people who know ho
On Thu, Nov 27, 2003 at 08:08:05PM -0800, Paul Hodges wrote:
:
: --- Larry Wall <[EMAIL PROTECTED]> wrote:
: > ... in fact, we may be limiting the creation of properties
: > to predeclared names, so that even
: >
: > return 0 but ture;
: >
: > can be caught at compile time.
:
: Excellent, s
--- Larry Wall <[EMAIL PROTECTED]> wrote:
> ... in fact, we may be limiting the creation of properties
> to predeclared names, so that even
>
> return 0 but ture;
>
> can be caught at compile time.
Excellent, so long as we can define new properties explicitly.
At the moment, I draw a comple
[EMAIL PROTECTED] (Larry Wall) writes:
> P.S. I think we deserve a $rubyometer-- for bypassing mixins.
I think you deserve loud and wild applause for an object model I want
to use Right Now Dammit.
--
Overall there is a smell of fried onions. (fnord)
On Thu, Nov 27, 2003 at 12:02:30AM -0700, Luke Palmer wrote:
: Here's a series of questions/confirmation requests about how properties
: work (but specifically run-time properties, not traits):
:
: Use C to assign a property to a I:
:
: $a = $b but foo; # $a has property foo, $b does no
On Thu, Aug 09, 2001 at 03:37:42AM +1000, Damian Conway wrote:
> Scott wrote:
>> What happens to C within stand-alone C statements? Do
>> C statements never stand alone?
>
> That's correct. I'd expect:
>
> die "Ungoverned 'when' statement (where's the 'given'???)"
That's weird.
> My personal preference would be for all such properties (traits?) to be
> reserved across all types - eg using 'prompt' on a hash gives a
> compile/run time error. This allows the compiler to catch certain types
> of typo and thinko, and also allows us to expand in future - eg when
Scott wrote:
> Hmm. C seems to be synonymous with C (almost)
>
>when ($foo) { ... } # Does this mean if ($_ eq $foo)?
> if ($foo) { ... }
A C is an whose "other half" is specified by a surrounding C.
> However ...
>
> > A C within a C's block causes
On Wed, Aug 08, 2001 at 08:25:57AM +1000, Damian Conway wrote:
>> More questions regarding the new 'given when' construct.
>> [ LABEL: ] given ( expr_1 ) {
>>[ when expr_2 : block ...]
>>expr_n [;]
>> }
>
> Not required. It's:
>
> [
Damian Conway <[EMAIL PROTECTED]> wrote:
>> There are a number of properties "built into" Perl 6. Nearly all of these
>> properties don't make sense across the board - eg, a scalar won't have a
>> dimension, a hash won't prompt, etc.
>>
>> So given the two different sets that y
> # >my $foo is const = 0 is true;
> # >
> # > $foo has the property const, while the value 0 in $foo has
> # > the property true.
> #
> # So, if I do
> #
> # my $foo is constant = new Counter(0);
> # $foo->increment # OK
>
> I think so.
Yep. Except the prop
Dan suggested:
> The syntax for variable and value properties are going to be different, I
> think, I just can't remember what it's going to be. (I think the colon's
> involved, but isn't it always?)
I think you're now channelling my de specula, not Larry's de jure. :-)
In A2, Larry
> More questions regarding the new 'given when' construct.
More answers (modulo Larry :-)
> 1) Is a 'when' clause required? Is it:
>
> [ LABEL: ] given ( expr_1 ) {
>when expr_2 : block
>[ when expr_3 : block ...]
>expr_n [;]
>
> Damian,
> You mentioned in E2 that the chomped property relies on the insep
> property of the filehandle (formerly $/). Can I extrapolate that
>$.
>$,
>$\
>$|
> will also be properties on filehandles? (How about
>$"
> for arrays?)
It's not
> There are a number of properties "built into" Perl 6. Nearly all of these
> properties don't make sense across the board - eg, a scalar won't have a
> dimension, a hash won't prompt, etc.
>
> So given the two different sets that you must consider (variable versus
> value, and
On Thursday 02 August 2001 10:38 pm, Edward Peschko wrote:
> Statement: $bar isnt my_prop;
>
> This makes $bar keep all of its properties, removing my_prop;
No. This gives $bar the negation of my_prop, whatever it may be. It may be
its removal, it may be something else.
> Anyways, just a clar
On Thursday 02 August 2001 08:47 pm, Dan Sugalski wrote:
> At 06:57 PM 8/2/2001 -0400, Bryan C. Warnock wrote:
> >Here's how I'm documenting it. Corrections requested.
> >
> >Properties are by Perl thingy. (scalar, array, hash, reference, blessed
> >reference?, file handle, etc)
>
> I think they
Arrgh. lets try this again (for examples)
Statement: $bar = $foo is my_prop = 0 is some_prop;
This makes $foo have 'my_prop' and 'some_prop' with the value 0 - and $bar have
'my_prop' and 'some_prop' with the value 0.
Statement: $bar = 0;
This makes $bar have no properties with the value 0 (i
On Friday 03 August 2001 04:09 pm, Brent Dax wrote:
> # %foo is constant = (a=>1, b=>$foo);
> #
> # are only the keys contant; or both the keys and values.
>
> Keys and values, I imagine.
>
> # i.e. which of these is illegal
> #
> # %foo{c} = 1; # error
> # %foo{a} = 2; # probably error, but it wo
> I think they're supposed to be both by perl thingie and by value. So:
>
>my $foo is const = 0 is true;
>
> $foo has the property const, while the value 0 in $foo has
> the property true.
So, if I do
my $foo is constant = new Counter(0);
$foo->increment # OK
my $bar = new Counter(0) is
Here's how I'm documenting it. Corrections requested.
Properties are by Perl thingy. (scalar, array, hash, reference, blessed
reference?, file handle, etc)
That allows different things to be 'foo', for the appropriate definition of
'foo'.
---
Second thought:
Scribbling Servant
At 07:28 PM 8/2/2001 -0700, Edward Peschko wrote:
> > Now that you've got me thinking about it, that brings up some interesting
> > questions.
> >
> > $bar = $foo is my_prop = 0 is some_prop;
> > ($bar = $foo is my_prop) = 0 is some_prop;
> > $bar = ($foo is my_prop) = 0 is some_prop;
>
>This is w
On Thu, 7 Jun 2001, Michael G Schwern wrote:
> On Wed, Jun 06, 2001 at 01:37:23AM -0500, Me wrote:
> > > B&D languages
> >
> > What's B&D?
>
> Bondage and Discipline, scum! You're not a good enough programmer to
> be trusted not to make mistakes! Now drop and give me fifty!
Hmmm...
From: <[EMAIL PROTECTED]>
To: "David L. Nicol" <[EMAIL PROTECTED]>
Sent: Friday, June 08, 2001 8:01 PM
Subject: Re: Properties and stricture and capabilities
> On Thu, Jun 07, 2001 at 08:24:33PM -0500, David L. Nicol wrote:
> > That would prevent further shoving of
On Thu, Jun 07, 2001 at 08:24:33PM -0500, David L. Nicol wrote:
> > Symbol table manipulation will work as long as your mucking about
> > doesn't alter the strict class's signature. ie. you can shove a code
> > ref onto the symbol table as long as a stub for that method was
> > defined at compile
Michael G Schwern wrote:
> Symbol table manipulation will work as long as your mucking about
> doesn't alter the strict class's signature. ie. you can shove a code
> ref onto the symbol table as long as a stub for that method was
> defined at compile time.
a read-only hash of any kind makes it
On Wed, Jun 06, 2001 at 01:37:23AM -0500, Me wrote:
>
> > Larry's MMV on that ;-)
>
> Man I really need to get up to speed with these
> acronyms. I know YMMV, is MMV a distant
> cousin perhaps?
Same idea, except it's Larry's Milage in question, rather than Yours.
dha
--
David H. Adler - <[EM
This is similar to the solution they use in Java. You have an interface,
which is compile time checked. Then, when you load a class at runtime, you
check at load time that it satisfies the interface. You either get an
exception right then, or you're fine.
Daniel
Michael G Schwern wrote:
> O
Michael G Schwern wrote:
> you can even do it now through ad hockery.
Or odd hackery.
:-)
--
John Porter
Michael G Schwern wrote:
> Basically, any class which wants to be type-checked at compile time.
I think the meaning of that is still not clear,
given what "strong typing" usually means.
--
John Porter
On Wed, Jun 06, 2001 at 01:37:23AM -0500, Me wrote:
> > B&D languages
>
> What's B&D?
Bondage and Discipline, scum! You're not a good enough programmer to
be trusted not to make mistakes! Now drop and give me fifty!
--
Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwe
On Wed, Jun 06, 2001 at 07:06:49PM -0700, Dave Storrs wrote:
> But if we did, how could we hope to get a good new Star Trek
> series? :>
You're still hoping for a new, good Star Trek series??? You must be a
Cubs fan.
--
Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~s
On Wed, Jun 06, 2001 at 10:28:41AM -0400, John Porter wrote:
> Michael G Schwern wrote:
> > It will have to go for strict classes. @ISA will have to be locked.
>
> "strict classes"?
> "strongly typed class"?
Can a man make up gibberish in peace? ;)
Basically, any class which wants to be type-c
Ok, I've realized a few things.
1) There's two sorts of type-checking going on here. Compile-time and
run-time.
2) Run-time type checking is fairly easy and imposes few limitations. In
fact, you can even do it now through ad hockery.
3) Compile-time type checking is a bit harder. Any modul
Damian Conway wrote:
> I very much doubt Perl is going to become significantly more statically
> analyzable in general. Though static determinacy is obviously a
> desirable thing, there are plenty of other B&D
Bondage and Discipline?
> languages that offer it
> in abundance. And the dynamic pow
On Tue, 5 Jun 2001, Michael G Schwern wrote:
> On Tue, Jun 05, 2001 at 01:34:35PM -0700, Daniel S. Wilkerson wrote:
> > I cannot imagine running an enterprise critical application
>
> As a complete digression, can we please strike the term "enterprise"
> from the English lexicon? Completely r
> > Afaict, even with use strict at its most strict, perl 6
> > can't (in practice) complain, at compile time, if
> >
> > $foo.Foun
> >
> > refers to an undeclared Foun.
>
> it is already detectable. from perldoc perlref:
Perhaps for perl 5, but, aiui, Damian confirmed
that my thi
Me wrote:
>
> Question 1:
>
> Afaict, even with use strict at its most strict, perl 6
> can't (in practice) complain, at compile time, if
>
> $foo.Foun
>
> refers to an undeclared Foun.
>
> Right?
it is already detectable. from perldoc perlref:
Perl will raise an except
Me wrote:
> I.Found your notion of a "sealed off namespace"
> intriguing. I have no idea what it meant just yet;
> I'm going to go read and think about it now.
I'll pitch some syntax:
# prevent modification to %reflexive:: like so:
package reflexive is closed;
# allow i
Me wrote:
>
> > [strict typing]
> >
> > Not a negative, but realize that many people find it
> > of less value than the annoyances it brings with it
> > (myself included)
>
> Michael, I don't know which is more impressive; the
> fact that use of a strictly typed language implies that
> a copy of
> [strict typing]
>
> Not a negative, but realize that many people find it
> of less value than the annoyances it brings with it
> (myself included)
Michael, I don't know which is more impressive; the
fact that use of a strictly typed language implies that
a copy of you would land on the poor un
Michael G Schwern wrote:
> It will have to go for strict classes. @ISA will have to be locked.
"strict classes"?
> my $meth = "foo";
> $obj->$meth(); # $obj->foo();
>
> This definately can't work if $obj is of a class which is strongly
> typed.
"strongly typed class"?
> This can
Michael G Schwern <[EMAIL PROTECTED]> writes:
> Consider the following... Foo is a poster-child for a strict class.
> Everything is predeclared and typed. Its entire hierarchy is rock
> solid. Someone uses Foo in their script and calls Foo->bar. They
> also use Bar, a module you installed a lon
"Daniel S. Wilkerson" <[EMAIL PROTECTED]> writes:
> Michael G Schwern wrote:
> > No subroutine refs. No dynamic inheritance. No autoloading. No
> > dynamic method calls. No symbol table manipulation. No eval. No
> > automatic method generation. (That's off the top of my head).
>
> You don'
>> And, if this is so, then isn't it impossible to have useful
>> stricture about variable properties, because any given
>> reference to a property might be instead a value property
>> unknown to the compiler?
>
> Yes.
So:
You can't have (variable or value) property strictur
> So, is it right to say that one can't use stricture to avoid
> use of mistyped user defined value attached properties?
> (Perhaps with the exception of references to a value
> property in the same lexical scope as assignments of
> that value?)
>
> And, if this is so, then i
>> Consider the code:
>>
>> my $foo = 1 is Found;
>> &bar($foo);
>>
>> sub bar { my $baz = shift; if ($baz.Found) { ...} }
>>
>> Does the value of $baz have the Found property?
>
> Yes.
>
>> If so, does the compiler know that?
>
> No. Because i
> Consider the code:
>
> my $foo = 1 is Found;
> &bar($foo);
>
> sub bar { my $baz = shift; if ($baz.Found) { ...} }
>
> Does the value of $baz have the Found property?
Yes.
> If so, does the compiler know that?
No. Because it only has the property at
> On Tue, Jun 05, 2001 at 04:38:24PM -0500, Me wrote:
> > Question 1:
> >
> > Afaict, even with use strict at its most strict, perl 6
> > can't (in practice) complain, at compile time, if
> >
> > $foo.Foun
> >
> > refers to an undeclared Foun.
> >
> > Right?
>
> Can't you hear the
>> Question 2:
>>
>> Afaict, even with use strict at its most strict, perl 6
>> can't (in practice) complain, at compile time, if
>>
>> $foo.Foun
>>
>> refers to an undeclared Foun.
>
> It could certainly warn you
Consider the code:
my $foo = 1
> Question 1:
>
> Afaict, even with use strict at its most strict, perl 6
> can't (in practice) complain, at compile time, if
>
> $foo.Foun
>
> refers to an undeclared Foun.
It could certainly warn you, but it can't object fatally since there's
always the p
On Tue, Jun 05, 2001 at 11:14:29PM +0100, Michael G Schwern wrote:
> my $meth = "foo";
> $obj->$meth(); # $obj->foo();
>
> I'm probably using the wrong terms.
>
> This definately can't work if $obj is of a class which is strongly
> typed.
You would do that in Java by using reflection.
On Tue, Jun 05, 2001 at 04:38:24PM -0500, Me wrote:
> Question 1:
>
> Afaict, even with use strict at its most strict, perl 6
> can't (in practice) complain, at compile time, if
>
> $foo.Foun
>
> refers to an undeclared Foun.
>
> Right?
Can't you hear the low roar from the strong-
On Tue, Jun 05, 2001 at 03:29:02PM -0700, Daniel S. Wilkerson wrote:
> It would be interesting for someone to measure that, however I doubt that it
> is so.
Oh, and look at what just showed up in my mailbox!
- Forwarded message from Tony Bowden <[EMAIL PROTECTED]> -
I think we should st
On Tue, Jun 05, 2001 at 05:49:30PM -0400, John Porter wrote:
> > By preventing lots of little gotchas, you free the mind to pay attention
> > to what it is doing rather than the most minute details of how to do
> > it. This is a quite powerful effect.
>
> Interesting you should mention this.
> I
John Porter wrote:
> Daniel S. Wilkerson wrote:
> > It is doubtful we shall have compilers that can tell you for example,
> > that you used the wrong algorithm.
>
> Right. I think that's what Schwern was getting at, when he said
> > > > > Type checking is nice, but its just one class of error-ch
On Tue, Jun 05, 2001 at 02:39:33PM -0700, Daniel S. Wilkerson wrote:
> Thank you, that's what I thought it might be. This can be done at
> compile time with a two-stage compilation. The first one writes the
> code that the second compiles. Then the checking can be done during
> the second stage
On Tue, Jun 05, 2001 at 01:34:35PM -0700, Daniel S. Wilkerson wrote:
> I cannot imagine running an enterprise critical application
As a complete digression, can we please strike the term "enterprise"
from the English lexicon? Completely redundant and drives me up the
wall. Almost as bad as "eco
Daniel S. Wilkerson wrote:
> It is doubtful we shall have compilers that can tell you for example,
> that you used the wrong algorithm.
Right. I think that's what Schwern was getting at, when he said
> > > > Type checking is nice, but its just one class of error-checking.
> By preventing lots
At 02:39 PM 6/5/2001 -0700, Daniel S. Wilkerson wrote:
>Thank you, that's what I thought it might be. This can be done at compile
>time with a two-stage
>compilation. The first one writes the code that the second
>compiles. Then the checking can be
>done during the second stage.
Not when the
I apologize. I royally screwed up my original post.
I had meant to ask two minor specific yes/no answer
type questions about properties and stricture, that
were mutually unrelated. Instead I asked one major
open ended one.
In the hope that I haven't completely blown any
chance of getting answers
Daniel S. Wilkerson wrote:
> If you call a method in Java, you can see right there which method you are
> calling.
> You can then lexically follow the inheritance tree and find out exactly
> what code really is called, what its signature is, and what it returns.
> Nothing dynamic is involved.
Pre
Thank you, that's what I thought it might be. This can be done at compile time with a
two-stage
compilation. The first one writes the code that the second compiles. Then the
checking can be
done during the second stage.
Daniel
Michael G Schwern wrote:
> On Tue, Jun 05, 2001 at 01:42:38PM
I flatter myself that I understand your point. It is doubtful we shall
have compilers that can tell you for example, that you used the wrong
algorithm.
However, perhaps I did not express my point as well as I could have. I
include the quote from Whitehead again, along with some others.
"By rel
On Tue, Jun 05, 2001 at 01:42:38PM -0700, Daniel S. Wilkerson wrote:
> Someone please tell me what automatic method generation is exactly.
package Foo;
sub AUTOLOAD {
my $method = $AUTOLOAD;
eval "sub $method { warn qq/Please do not call this method again.\n/ }"
goto &$method;
}
--
On Tue, Jun 05, 2001 at 01:42:38PM -0700, Daniel S. Wilkerson wrote:
> Someone please tell me what automatic method generation is exactly.
Its the generation of large numbers of similar methods which would
otherwise be really tedious to write out by hand, such as accessor
methods. Without this,
If you call a method in Java, you can see right there which method you are
calling. You can then lexically follow the inheritance tree and find out exactly
what code really is called, what its signature is, and what it returns. Nothing
dynamic is involved.
One might ask for other featues, but I
1 - 100 of 172 matches
Mail list logo
