Dan Sugalski <[EMAIL PROTECTED]> writes:
> Absolutely. It makes things generally faster and easier for perl, and
> doesn't affect python or ruby. Yeah, I know, immutable values make a
> number of static compilation things better with sufficient engineering
> resources, but we're not particularly st
At 11:00 AM +0530 1/6/03, Gopal V wrote:
If memory serves me right, Dan Sugalski wrote:
>> Why would we want to avoid this? It looks exactly like what ought to
>> happen.
If you can provide that in-vm , it would be a lot faster ...(hmm, that's
one argument that should convince you ;)
Stru
If memory serves me right, Dan Sugalski wrote:
> >> Why would we want to avoid this? It looks exactly like what ought to
> >> happen.
If you can provide that in-vm , it would be a lot faster ...(hmm, that's
one argument that should convince you ;)
But like I said , I need lots of sticky notes
At 3:29 PM -0500 1/5/03, attriel wrote:
> At 6:56 PM +0530 1/4/03, Gopal V wrote:
If memory serves me right, Erik Bågfors wrote:
> >> would a be able to modify itself ? (unfortunately C# allows
that)
> >
To clarify here's my example ...
=cut
using System;
public struct MyStruct
{
int
> At 6:56 PM +0530 1/4/03, Gopal V wrote:
>>If memory serves me right, Erik Bågfors wrote:
>>> > >> would a be able to modify itself ? (unfortunately C# allows
>>> that)
>>> > >
>>
>>To clarify here's my example ...
>>
>>=cut
>>
>>using System;
>>public struct MyStruct
>>{
>> int val;
>>
At 6:56 PM +0530 1/4/03, Gopal V wrote:
If memory serves me right, Erik Bågfors wrote:
> >> would a be able to modify itself ? (unfortunately C# allows that)
> >
To clarify here's my example ...
=cut
using System;
public struct MyStruct
{
int val;
public MyStruct(int x){ val=x; }
public
On Jan-04, Gopal V wrote:
> So, workarounds are possible .. and neither the host nor the compiler
> is there yet ;) ...
Good point -- we'd better speed up on this Parrot stuff, so we can
push more of the really hard things onto you compiler guys. ;)
If memory serves me right, Erik Bågfors wrote:
> > >> would a be able to modify itself ? (unfortunately C# allows that)
> > >
To clarify here's my example ...
=cut
using System;
public struct MyStruct
{
int val;
public MyStruct(int x){ val=x; }
public void Modify(){ val=
On Sat, 2003-01-04 at 04:05, Dan Sugalski wrote:
> At 7:27 PM +0100 1/3/03, Erik Bågfors wrote:
> >On Sat, 2003-01-04 at 00:28, Gopal V wrote:
> >> If memory serves me right, Dan Sugalski wrote:
> >> > language-level "we're object-oriented dammit!" objects, not the
> >> > lower-level stuff we're
At 4:58 AM +0530 1/4/03, Gopal V wrote:
If memory serves me right, Dan Sugalski wrote:
language-level "we're object-oriented dammit!" objects, not the
lower-level stuff we're currently working with) should/will behave.
yay ! ... finally !
reference-style objects and non-reference values.
At 7:27 PM +0100 1/3/03, Erik Bågfors wrote:
On Sat, 2003-01-04 at 00:28, Gopal V wrote:
If memory serves me right, Dan Sugalski wrote:
> language-level "we're object-oriented dammit!" objects, not the
> lower-level stuff we're currently working with) should/will behave.
yay ! ... finally !
On Sat, 2003-01-04 at 00:28, Gopal V wrote:
> If memory serves me right, Dan Sugalski wrote:
> > language-level "we're object-oriented dammit!" objects, not the
> > lower-level stuff we're currently working with) should/will behave.
>
> yay ! ... finally !
The moment we've all been waiting for :
If memory serves me right, Dan Sugalski wrote:
> language-level "we're object-oriented dammit!" objects, not the
> lower-level stuff we're currently working with) should/will behave.
yay ! ... finally !
> reference-style objects and non-reference values.
How large can a non-reference value be
Dan Sugalski wrote:
Still, for 'real' OO, it's all reference object stuff, so things should
Just Work. The pending questions about
... strings still is pending ;-)
Remember string_set ins substr and 50% live performance increase.
Do we want do reuse string headers like PMCs (and change sema
14 matches
Mail list logo
