> I just want to hit this point a little more, to make sure we're actually
> in agreement.
Ok, ok... sorry about this. I've been hammering away at a stubborn gray area
and now I'm seeing that "duh!" it's all right there. Yes, of course 'int'
would be a subclass of Scalar. You know, it's silly...
Steve Fink wrote:
>
> But then what does my $x = BlueFoo->new(); print
> "$x" do, assuming there is a BlueFoo::STRINGIFY? Print
> "BlueFoo=HASH(0x0b38134)"?
The current thinking it to preserve the default behavior, which would be
to print out the ref info, UNLESS there is a STRING function. That
Matt Youell wrote:
>
> Originally I was trying to avoid explicit typing through new keywords, like
> 'int'. So the latter option would have been the case. But after Nathan
> Wiger's reply to my RFC, I realized that either syntax would work. Under one
> scenario, 'int', as in your example, would si
Tom Christiansen wrote:
> Hm I don't recall C++ ever thinking to overload the control-flow
> operators ("&&", "||", "," (that is, comma), and "?:"). Why not?
> Even if their "a && b" should produce a more mundane 1 or 0, one
> still might wish control.
>
'&&', '||', et al are just operato
>I can currently overload + < > * to do this, but not &&. That's broken.
Hm I don't recall C++ ever thinking to overload the control-flow
operators ("&&", "||", "," (that is, comma), and "?:"). Why not?
Even if their "a && b" should produce a more mundane 1 or 0, one
still might wish contr
> What about
>
> sub somename : method (@args) {...}
>
> And leaving your$self some other way at the object?
That's the idea. By default you get the invocant in $_[0],
but you can have the compiler extract it for you via C.
Then you get to choose your access mechanism (lexica
>I think they would *improve* readability. Certainly over $_[0], and
>even over:
> sub method {
> my ($self, @args) = @_;
> ...
> }
>I'm *forever* writing that and just it clutters up the code.
What about
sub somename : method (@args) {
...
I like a lot of what is in this RFC. It rings true for me, since my favorite CPAN
modules are OO. The less I need to learn about a package, the happier I tend to be.
Also, powerful objects tend to be slower (though it's getting better).
I haven't seen all of the discussion reguarding this RF
On Mon, Aug 28, 2000 at 01:32:49PM -0700, Nathan Wiger wrote:
> We can pick self(). Or this(). Or me(). Or context(). Or invocant().
>
> Or $ME. Or $SELF. Or $THIS. Or $CONTEXT. Or $INVOCANT.
>
> But we have to f**king pick *something*!!!
I'll just wait for Rule #1 to be exercised, personally
Damian Conway wrote:
>
> I wouldn't be averse to C as the default and C as a sop to
> the Cerites and C<$ME>ophiles. But *they* might be!
This is baloney. I agree, we need to *pick something*!!
What should we do, make a "rename" pragma so everyone can be happy?
use rename want => '$NEED', && =
On 8/28/00 3:53 PM, Damian Conway wrote:
>> Too much B&D for a Monday?
>
> No. I *do* have sympathy with the desire for One True Way, but *only* if the
> access function is called C (my own religion ;-).
>
> And *that's* the problem.
Yeah, there'll never be consensus on this list or in the comm
> I was talking about the hypothetical situation where you're (re)using or
> modifying a bunch of code or classes written by different people and you
> constantly have to be aware of which self-thingie to use in which file or
> package or whatever. Yeah, you can just glance up to the
On 8/28/00 3:35 PM, Damian Conway wrote:
>> ...while also giving the compiler enough information to allow such
>> invocant access to execute in an optimized manner...right? C'mon,
>> I'm dying here thinking that all this (admittedly cool) stuff is
>> gonna end up giving Perl 6 even more OO overhea
> > The use invocant was proposed as a way to maintain backwards
> > compatibility and yet give everyone the invocant access syntax he
> > or she personally favours.
>
> ...while also giving the compiler enough information to allow such
> invocant access to execute in an optimize
On 8/28/00 3:09 PM, Damian Conway wrote:
>> (Or, was it already intended that the implementation of 'use
>> invocant' might be some sort of compile-time macro?)
>
> No. I think a macro facility for Perl should be more general than just
> whacking some code in at the start of every subroutine.
>
> What I meant to say was more along the lines of "if this could be done as a
> macro, does it need to be a pragma, or could it be part of a standard macro
> package?"
>
> And, secondly, "if this *is* part of a standard macro package, wouldn't it
> be cool to let it shove arbitr
> > (Or, was it already intended that the implementation of 'use
> > invocant' might be some sort of compile-time macro?)
> No. I think a macro facility for Perl should be more general than just
> whacking some code in at the start of every subroutine.
Yes. I didn't phrase my comments well
> (Or, was it already intended that the implementation of 'use
> invocant' might be some sort of compile-time macro?)
No. I think a macro facility for Perl should be more general than just
whacking some code in at the start of every subroutine.
The use invocant was proposed as a way to ma
> Summary: I think these should all simply break down into a single
> Boolification test of some sort, as occurs already with operator
> overload.
Counter-summary: Although the high and low precedence binary ops could be
rolled together, the current version of operator o
At 11:28 AM 8/28/00 -0700, Steve Fink wrote:
>Dan Sugalski wrote:
> >
> > If the vtable stuff goes into the core perl engine (and it probably will,
> > barring performance issues), then what could happen in the
> >
> > my Foo $bar;
> >
> > case would be that all the vtable functions for Foo are
Dan Sugalski wrote:
>
> If the vtable stuff goes into the core perl engine (and it probably will,
> barring performance issues), then what could happen in the
>
> my Foo $bar;
>
> case would be that all the vtable functions for Foo are taken as specially
> named subs/methods in the Foo packag
Damian Conway:
> My forthcoming proposal will be that invocants still be passed as $_[0]
> by default, but that there be a pragma allowing $_[0] to be automagically
> shifted somewhere else during dispatch. For example:
>
>
> sub method { print "I was called through: $_[0]";
>
On Sun, Aug 27, 2000 at 07:54:35PM -0700, Nathan Wiger wrote:
> And why is passing $self in $_[0] a good thing?
Because it eliminates a butt-load of translation to convert Perl5
programs to Perl6 programs. Rather than tracking down each and every
sub and figuring out if it's used as a method o
Summary: I think these should all simply break down into a single
Boolification test of some sort, as occurs already with operator
overload.
>LOGHIGHAND Called in && context
>LOGHIGHOR Called in || context
>LOGLOWAND Called in and context
>LOGLOWOR Called in or context
>LOGIFE
On Sun, 27 Aug 2000 06:14:00 -0700, Matt Youell wrote:
>So an int gets stored as two bytes and not
>four or eight.
Gee, I thought it was more like 30. The savings in bytes don't look too
impressive in this case. 4 byte addition is as fast as 2 byte addition
on most pmodern platforms -- and you
I've read over 161 again and I'm starting to see areas where I can clarify
things greatly. I apologize for the confusion. I'll make mods to the RFC in
the near future, after I get more feedback from you all.
Here are my goals as they probably should have been stated in the RFC:
- Concentrate re
26 matches
Mail list logo
