OOBit

classic Classic list List threaded Threaded
84 messages Options
12345
Reply | Threaded
Open this post in threaded view
|

OOBit

Nilson
Hi guys,

Could you send me opinions about OOBIT patch? I would appreciate any opinion that could help me to decide the patch's future.

Status Report:

***********
OOBIT on tt field of values
status:  done
runtime cost:  1 additional AND on type read and 1 XOR, 1 AND and 1 OR on type write.

***********
OOBIT ooset and ooget functions
status: done

***********
Language extension to indicate REQUIRES SELF
status: done
how: adding METHOD keyword (could be done without a new keyword)

Example:

a ={}
a.name = 'Lua'
a.print = method() print('Name: ',a.name) end   -- solves a:f=function()...
a:print()                                       -- still uses colons

>> Name: Lua

***********
Set the OOBIT.of a function when it REQUIRES SELF
status: on queue (next thing to do)

***********
THE MAIN GOAL: Using just the dot syntax, automatically add a self parameter when a function requires it.
status - planning, prototyping

ESTIMATED COST (current approach) :

* 1 additional VM operation OP_AUTOSELF: it is an OP_SELF generated automatically (without colon)

* 1 extra stack parameter on every table call without colon, <path-to-table>.field()   (see 1)

* 4  to 16 additional fast/machine level operations to decide how to handle each CALL

* 4 to 10 additional fast/simple machine level operations to cleanup after the call

* a couple of additional integer fields


1 - I could not find a way to preserve the table without use of the stack. I think it´s not possible, but I will try a little more.
IMHO, this is the more expensive cost.

***********
PROS

* A safe way to eliminate the colon usage in function calls.

*
"REQUIRES SELF" enhances the function´s semantics what helps to detect "missing self" errors.

* If OOBIT is allowed to be set in other values - like tables - it could help to enhance the whole Lua´s OO experience.


CONS

* The extra runtime cost will be (a little bit) higher, whether the programmer use only dots in table calls or not.

*
To some platforms and/or applications, the extra runtime cost could be too expensive.

* I don´t know the impact on LUA JIT.

***********
Well, in your opinion, it´s worth?

You can send your
answer directly to my email, if the mailing list's rules allow (I´m new here).


Thanks.

--
Nilson


Reply | Threaded
Open this post in threaded view
|

Re: OOBit

Rena
On Sun, Sep 26, 2010 at 13:44, Nilson <[hidden email]> wrote:

> Hi guys,
>
> Could you send me opinions about OOBIT patch? I would appreciate any opinion
> that could help me to decide the patch's future.
>
> Status Report:
> ***********
> OOBIT on tt field of values
> status:  done
> runtime cost:  1 additional AND on type read and 1 XOR, 1 AND and 1 OR on
> type write.
>
> ***********
> OOBIT ooset and ooget functions
> status: done
>
> ***********
> Language extension to indicate REQUIRES SELF
> status: done
> how: adding METHOD keyword (could be done without a new keyword)
>
> Example:
>
> a ={}
> a.name = 'Lua'
> a.print = method() print('Name: ',a.name) end   -- solves a:f=function()...
> a:print()                                       -- still uses colons
>
>>> Name: Lua
>
> ***********
> Set the OOBIT.of a function when it REQUIRES SELF
> status: on queue (next thing to do)
>
> ***********
> THE MAIN GOAL: Using just the dot syntax, automatically add a self parameter
> when a function requires it.
> status - planning, prototyping
>
> ESTIMATED COST (current approach) :
>
> * 1 additional VM operation OP_AUTOSELF: it is an OP_SELF generated
> automatically (without colon)
>
> * 1 extra stack parameter on every table call without colon,
> <path-to-table>.field()   (see 1)
>
> * 4  to 16 additional fast/machine level operations to decide how to handle
> each CALL
>
> * 4 to 10 additional fast/simple machine level operations to cleanup after
> the call
>
> * a couple of additional integer fields
>
>
> 1 - I could not find a way to preserve the table without use of the stack. I
> think it´s not possible, but I will try a little more.
> IMHO, this is the more expensive cost.
>
> ***********
> PROS
>
> * A safe way to eliminate the colon usage in function calls.
>
> * "REQUIRES SELF" enhances the function´s semantics what helps to detect
> "missing self" errors.
>
> * If OOBIT is allowed to be set in other values - like tables - it could
> help to enhance the whole Lua´s OO experience.
>
>
> CONS
>
> * The extra runtime cost will be (a little bit) higher, whether the
> programmer use only dots in table calls or not.
>
> * To some platforms and/or applications, the extra runtime cost could be too
> expensive.
>
> * I don´t know the impact on LUA JIT.
>
> ***********
> Well, in your opinion, it´s worth?
>
> You can send your answer directly to my email, if the mailing list's rules
> allow (I´m new here).
>
>
> Thanks.
>
> --
> Nilson
>
>
>

a.print = method() print('Name: ',a.name)
not self.name?

--
Sent from my toaster.

Reply | Threaded
Open this post in threaded view
|

Re: OOBit

Nilson
On Sun, Sep 26, 2010 at 6:32 PM, HyperHacker <[hidden email]> wrote:
On Sun, Sep 26, 2010 at 13:44, Nilson <[hidden email]> wrote:
> Hi guys,
>
> Could you send me opinions about OOBIT patch? I would appreciate any opinion
> that could help me to decide the patch's future.
>
> Status Report:
> ***********
> OOBIT on tt field of values
> status:  done
> runtime cost:  1 additional AND on type read and 1 XOR, 1 AND and 1 OR on
> type write.
>
> ***********
> OOBIT ooset and ooget functions
> status: done
>
> ***********
> Language extension to indicate REQUIRES SELF
> status: done
> how: adding METHOD keyword (could be done without a new keyword)
>
> Example:
>
> a ={}
> a.name = 'Lua'
> a.print = method() print('Name: ',a.name) end   -- solves a:f=function()...
> a:print()                                       -- still uses colons
>
>>> Name: Lua
>
> ***********
> Set the OOBIT.of a function when it REQUIRES SELF
> status: on queue (next thing to do)
>
> ***********
> THE MAIN GOAL: Using just the dot syntax, automatically add a self parameter
> when a function requires it.
> status - planning, prototyping
>
> ESTIMATED COST (current approach) :
>
> * 1 additional VM operation OP_AUTOSELF: it is an OP_SELF generated
> automatically (without colon)
>
> * 1 extra stack parameter on every table call without colon,
> <path-to-table>.field()   (see 1)
>
> * 4  to 16 additional fast/machine level operations to decide how to handle
> each CALL
>
> * 4 to 10 additional fast/simple machine level operations to cleanup after
> the call
>
> * a couple of additional integer fields
>
>
> 1 - I could not find a way to preserve the table without use of the stack. I
> think it´s not possible, but I will try a little more.
> IMHO, this is the more expensive cost.
>
> ***********
> PROS
>
> * A safe way to eliminate the colon usage in function calls.
>
> * "REQUIRES SELF" enhances the function´s semantics what helps to detect
> "missing self" errors.
>
> * If OOBIT is allowed to be set in other values - like tables - it could
> help to enhance the whole Lua´s OO experience.
>
>
> CONS
>
> * The extra runtime cost will be (a little bit) higher, whether the
> programmer use only dots in table calls or not.
>
> * To some platforms and/or applications, the extra runtime cost could be too
> expensive.
>
> * I don´t know the impact on LUA JIT.
>
> ***********
> Well, in your opinion, it´s worth?
>
> You can send your answer directly to my email, if the mailing list's rules
> allow (I´m new here).
>
>
> Thanks.
>
> --
> Nilson
>
>
>

a.print = method() print('Name: ',a.name)
not self.name?

--
Sent from my toaster.

 
Yes, it should be. thank you.

Errata1:

a ={}
 a.name = 'Lua'
a.print = method() print('Name: ',self.name) end   -- solves a:f=function()...
a:print() 


Errata2:


CONS

 * The (xxxx) runtime cost will be (a little bit) higher, whether the programmer use only dots in table calls or not.


--
Nilson
Reply | Threaded
Open this post in threaded view
|

Re: OOBit

Gunnar Zötl
In reply to this post by Nilson

> THE MAIN GOAL: Using just the dot syntax, automatically add a self parameter when a function requires it.
> status - planning, prototyping

I am not too fond of this. Considering that there are no explicit objects, and tables are the one-size-fits-all complex data type, I kinda like that lua syntax explicitely distinguishes between calling a function that is stored in a table (dot) and calling said function as a method. This adds magic and introduces behaviour that is not imediately clear when reading the code. As in:

some.stuff()

is "stuff" a method of "some" or just a function? This is immediately clear with the current syntax.

However, that's just me and I know that some people want to do everything using dot notation only, so they might like it.

Gunnar


Reply | Threaded
Open this post in threaded view
|

Re: OOBit

Jonathan Castello-2
On Mon, Sep 27, 2010 at 3:36 AM, Gunnar Zötl <[hidden email]> wrote:
> However, that's just me and I know that some people want to do everything using dot notation only, so they might like it.

Colon notation makes me extremely paranoid. Since t:method() is just
sugar for t.method(t), anyone can replace 't' in the argument list
with some other, unrelated table. And it's extremely easy to forget to
use colon instead of dot - I constantly slip up accidentally. When I
have an object, if I'm calling a method on that object, I like the
assurance that this "message", per se, is going to my object. I always
build my own objects to use closures, binding methods to objects so I
can just use dot notation.

~Jonathan

Reply | Threaded
Open this post in threaded view
|

Re: OOBit

steve donovan
On Mon, Sep 27, 2010 at 12:53 PM, Jonathan Castello <[hidden email]> wrote:
> Colon notation makes me extremely paranoid. Since t:method() is just
> sugar for t.method(t), anyone can replace 't' in the argument list
> with some other, unrelated table.

But library code should always check for  'bad self', at least in an
ideal universe ;)

Closures can be expensive for _lots_ of objects of the same class.

steve d.

Reply | Threaded
Open this post in threaded view
|

Re: OOBit

Nilson
In reply to this post by Gunnar Zötl
>> THE MAIN GOAL: Using just the dot syntax, automatically add a self parameter when a function requires it.
>> status - planning, prototyping
>
> I am not too fond of this. Considering that there are no explicit objects, and tables are the one-size-fits-all complex data type, I kinda like that lua syntax explicitely distinguishes between calling a function that is stored in a table (dot) and calling said function as a method. This adds magic and introduces behaviour that is not imediately clear when reading the code. As in:
>
> some.stuff()
>
> is "stuff" a method of "some" or just a function? This is immediately clear with the current syntax.
>

You could continue to use " some:stuff() " as a programming style

Using OOBit:

a={}
a.name = 'Lua'
a.f = method(ver) print('Name: '..self.name..' '..ver) end

a.f('5.1.4')  -- works
a:f('5.1.4')  -- works too !!
a.f(a,'5.1.4') -- Fails without an error: 2 selfs. (see 1)

OPTION 1 (I like more)
f(a,'5.1.4') -- error "method requires a table call"
f('5.1.4') -- error "method requires a table call" (see 2)

OPTION 2  ( compatibility way )
f(a,'5.1.4') -- works
f('5.1.4') -- Fails without an automatic error

Perhaps an oocompatibility() function (irreversible) could select
OPTION2 ( in a LuaState basis). It could be useful to handle previous
code.

*****
Traditional way

  function a:g(ver) print('Name: '..self.name..' '..ver) end

For compatibility with whole previous code, functions declared like g,
could maintain the traditional behavior .

*****
Another option is to use set the OOBit of a table (perhaps with a new
keyword) to activate, in table calls, the method behavior of:

1) traditional functions:

b = new {}  -- or ooset( {} )
b = a.g

a.g('5.1.4') -- fails
a:g('5.1.4') -- works
b.g('5.1.4') -- works
b:g('5.1.4') -- works

2) All functions, including methods.

Notes

1) This could cause a compatibility problem with legacy code if you
pass a "method" as a parameter to a library that makes a call like "
table.param(table, ... ) " instead of "  param(table, ... )  ". That
would be rare, but worth mentioning.

2) Can catch an error that current implementation cannot.

---
Nilson

Reply | Threaded
Open this post in threaded view
|

Re: OOBit

Jonathan Castello-2
In reply to this post by steve donovan
On Mon, Sep 27, 2010 at 3:59 AM, steve donovan
<[hidden email]> wrote:
> But library code should always check for  'bad self', at least in an
> ideal universe ;)

Even if 't' and the other table have the same type, it's still not a
good thing. Lets take inheritance as an example: Assume I have a type
Foo and a derived type Bar, each with a method 'baz', and instances
'f' and 'b' respectively. I expect b:baz() to call Bar's baz on b. But
if I used f.baz(b) instead, I'm actually calling Foo's baz on b. And I
can't directly disallow this because if Bar didn't define its own
'baz', it would be perfectly valid for b:baz() to call Foo's baz
instead.

> Closures can be expensive for _lots_ of objects of the same class.

I define the methods once as locals, and use smaller closures to call
the method with the object as an argument. It can potentially create
lots of closures, yes, but the waste is kept to a minimum. And I like
the assurance that it can't be circumvented without access to the
debug table (because I use newproxy() to create the objects, and I put
data in the userdatum's environment).

~Jonathan

Reply | Threaded
Open this post in threaded view
|

Re: OOBit

steve donovan
On Mon, Sep 27, 2010 at 8:59 PM, Jonathan Castello <[hidden email]> wrote:
> 'f' and 'b' respectively. I expect b:baz() to call Bar's baz on b. But
> if I used f.baz(b) instead, I'm actually calling Foo's baz on b.

I thought that was a feature ;)

> lots of closures, yes, but the waste is kept to a minimum. And I like
> the assurance that it can't be circumvented without access to the
> debug table (because I use newproxy() to create the objects, and I put
> data in the userdatum's environment).

I suppose there are situations where you simply cannot trust your
users (or co-workers), but then sandboxing is the way forward.

steve d.

Reply | Threaded
Open this post in threaded view
|

Re: OOBit

Jonathan Castello-2
On Tue, Sep 28, 2010 at 12:17 AM, steve donovan
<[hidden email]> wrote:
> I suppose there are situations where you simply cannot trust your
> users (or co-workers), but then sandboxing is the way forward.

My particular area of interest with Lua is sandboxing, so yes. I
always try to think about how things can be circumvented. I use this
particular OO methodology so I can lock down the interface to exactly
what I want.

~Jonathan

Reply | Threaded
Open this post in threaded view
|

Re: OOBit

Javier Guerra Giraldez
In reply to this post by steve donovan
On Tue, Sep 28, 2010 at 2:17 AM, steve donovan
<[hidden email]> wrote:
> On Mon, Sep 27, 2010 at 8:59 PM, Jonathan Castello <[hidden email]> wrote:
>> 'f' and 'b' respectively. I expect b:baz() to call Bar's baz on b. But
>> if I used f.baz(b) instead, I'm actually calling Foo's baz on b.
>
> I thought that was a feature ;)

absolutely.

every now and then there appears some project to 'free from the
dot/colon choice', fortunately these efforts are typically short lived

--
Javier

Reply | Threaded
Open this post in threaded view
|

Re: OOBit

Nilson
On Tue, Sep 28, 2010 at 12:14 PM, Javier Guerra Giraldez
<[hidden email]> wrote:

>>> 'f' and 'b' respectively. I expect b:baz() to call Bar's baz on b. But
>>> if I used f.baz(b) instead, I'm actually calling Foo's baz on b.
>>
>> I thought that was a feature ;)
>
> absolutely.
>
> every now and then there appears some project to 'free from the
> dot/colon choice', fortunately these efforts are typically short lived
>

Javier,

I would like to clarify two things:

a) The patch does not forbid you to use the classic way. And even if
you uses the REQUIRES SELF semantic (currently signalized by the
"method" keyword) you can still use the colon. In fact, the only
severe incompatibility occurs in scenarios like the example above,
that seems to be, for the OO paradigm as the "goto" was for the
structured programing. So, as in PASCAL and C the goto still exists,
the classical way should continue to address this kind of requirement
- but, like the goto - should be used with caution.

b) The patch introduces a new semantic concept to Lua. The OOBit can
represent more than an REQUIRE SELF It says that a function is a
method. What for? Lua could, for example, detect - during the
execution - if the access to an field of the self object  is being
performed inside a class method or not. This could "create a new way"
(I suppose)  to control field's visibility outside a class.

--
Nilson

Reply | Threaded
Open this post in threaded view
|

Re: OOBit

Javier Guerra Giraldez
On Tue, Sep 28, 2010 at 3:26 PM, Nilson <[hidden email]> wrote:
> Lua could, for example, detect - during the
> execution - if the access to an field of the self object  is being
> performed inside a class method or not.

you're creating two types of functions. if you want a type checking
language you know where to find them.

--
Javier

Reply | Threaded
Open this post in threaded view
|

Re: Re: OOBit

Gunnar Zötl
In reply to this post by Nilson
I meant to comment ion this before:

> a) The patch does not forbid you to use the classic way. And even if
> you uses the REQUIRES SELF semantic (currently signalized by the
> "method" keyword) you can still use the colon.

it is not so much about what I can do, but more about what kind of code I will find. As I said before, I consider the lack of builtin magic behaviour (apart from the meta-stuff, which allows for some weird stuff) in lua a boon. And I honestly don't see what the fuss is about with the colons and all...

> that seems to be, for the OO paradigm as the "goto" was for the
> structured programing. So, as in PASCAL and C the goto still exists,
> the classical way should continue to address this kind of requirement
> - but, like the goto - should be used with caution.

well, for one, lua is not an OO language. And I would not want it to become one. Neither do, from what I gather, the authors. And, as Javier mentioned, these dotty thingy discussions die down rather quickly, so I don't really see a strong interest for this in the lua community either.

So I don't think your proposal is going to make it into the main lua codebase, and as far as I am concerned, that is a good thing. Nonetheless, make it a lua power patch and put it on the wiki next to the other dotty things, and it will probably find its users.

Gunnar


Reply | Threaded
Open this post in threaded view
|

Re: Re: OOBit

Tomás Guisasola-2
  Hi Gunnar

>> that seems to be, for the OO paradigm as the "goto" was for the
>> structured programing. So, as in PASCAL and C the goto still exists,
>> the classical way should continue to address this kind of requirement
>> - but, like the goto - should be used with caution.
>
> well, for one, lua is not an OO language. And I would not want it to become one. Neither do, from what I gather, the authors. And, as Javier mentioned, these dotty thingy discussions die down rather quickly, so I don't really see a strong interest for this in the lua community either.
>
> So I don't think your proposal is going to make it into the main lua codebase, and as far as I am concerned, that is a good thing. Nonetheless, make it a lua power patch and put it on the wiki next to the other dotty things, and it will probably find its users.
  I would say exactly that!  I like the fact that we are not tied
to objects in Lua.  We can write OO-like code but we are not forced to.

>>> 'f' and 'b' respectively. I expect b:baz() to call Bar's baz on b. But
>>> if I used f.baz(b) instead, I'm actually calling Foo's baz on b.
>>
>> I thought that was a feature ;)
>
>absolutely.
  As Steve and Javier mentioned earlier, I also think that is a
feature :-)

  Regards,
  Tomás
Reply | Threaded
Open this post in threaded view
|

Re: Re: OOBit

Nilson
In reply to this post by Gunnar Zötl
On Wed, Sep 29, 2010 at 5:03 AM, Gunnar Zötl <[hidden email]> wrote:

> it is not so much about what I can do, but more about what kind of code I will find. As I said before, I consider the lack of builtin magic behaviour (apart from the meta-stuff, which allows for some weird stuff) in lua a boon. And I honestly don't see what the fuss is about with the colons and all...
>
First, thanks for your post.

Why do you think that time to time people suggest a colon eliminate solution?

IMHO, for some Lua's users, the colon seems to be like a column in the
middle of a passage in a house. They understant why the architect put
it there, although it seems a little strange. But as the people are
adaptable and love Lua's elegant power and features, while the time
goes on, the colon (the column in the middle of passage) becomes a
natural thing. And if you give enough time, you can even heard: Why
the other languages do not have a colon?

Ahhnn, the magic behavior would be optional. If you don't like it,
just don´t use it.

>> that seems to be, for the OO paradigm as the "goto" was for the
>> structured programing. So, as in PASCAL and C the goto still exists,
>> the classical way should continue to address this kind of requirement
>> - but, like the goto - should be used with caution.
>
> well, for one, lua is not an OO language. And I would not want it to become one. Neither do, from what I gather, the authors. And, as Javier mentioned, these dotty thingy discussions die down rather quickly, so I don't really see a strong interest for this in the lua community either.
>
I agree that Lua is not a "out of the box" OO language, but has
features that, among other things, intend to allow a very flexible OO
behavior/implementation using it.  The OO thing seems to be so
important that PiL has a whole chapter about it and Lua itself has the
colon, that:

* simulates a kind of method definition
* simulates the "OO style call"
* improves performance eliminating an extra "push" - OP_SELF.

With colon, the OO style is not usual and requires a little extra
mental effort to use (dot or colon?), although is elegantly logic.

The patch's idea was to take a little step further, improving the
Lua's OO simulation with an OObit. The patch puts a internal mark on
functions and SELF parameter, which gives a certain "consciousness" to
LVM that is happening a "table call. What to do with it?

> So I don't think your proposal is going to make it into the main lua codebase, and as far as I am concerned, that is a good thing.
>
I don't know the future of the patch - I already request comments
about it. (This is a cue to someone be rude - please don´t).

> Nonetheless, make it a lua power patch and put it on the wiki next to the other dotty things, and it will probably find its users.
>
I am newbie here. If you read my previous messages, you will see that
I was asking for comments about the patch before I write it.  I
thought that I could use this mailing list with this purpose, am I
wrong?

By the way:

* The OOBit patch brought me the idea of the CONST patch (70% done -
benchmarking).

* To efficiently implement the CONST patch, I accidentally made a ***
LVM optimization *** that reduced up to 4-5% (measured in a  x86
computer with MSVC) the "interpretation time" of some sort of Lua's
programs (full of OP_SETTABLE instructions). I don't know if this
optimization will be efficient in any platform and  I cannot do the
tests by myself - help needed.

* a LVM optimization that makes Lua even faster is a good thing for
everyone, isn´t it?

IMHO, we never know where good will and hard work can lead. Why not be
generously patient if you don't feel a uncontrollable desire to help?

Cheers,

Nilson

Reply | Threaded
Open this post in threaded view
|

Re: Re: OOBit

Nilson
In reply to this post by Tomás Guisasola-2
Oi Tomas,

On Wed, Sep 29, 2010 at 8:51 AM, Tomas Guisasola Gorham
<[hidden email]> wrote:
>
>        I would say exactly that!  I like the fact that we are not tied
> to objects in Lua.  We can write OO-like code but we are not forced to.
>

As a C programmer, I agree with you. I really like to receive a
pointer to a memory position and have the freedom to choose how to
handle that set of bytes. I´m not joking.

But C also offers a more controlled way to handle data with types and
"function propotypes" while maintaining the classical way too. IMO, it
does that to help the programmers, not to "imprision" them. The OOBit
patch has the same intent: help.

Please note. I'm not try to imposing the OOBit patch ( an impossible
intention ). I'm just try to clarify its purpose whenever I think it
is misunderstood.

--
Nilson

Reply | Threaded
Open this post in threaded view
|

Re: OOBit

Tomás Guisasola-2
  Hi Nilson

> As a C programmer, I agree with you. I really like to receive a
> pointer to a memory position and have the freedom to choose how to
> handle that set of bytes. I´m not joking.
>
> But C also offers a more controlled way to handle data with types and
> "function propotypes" while maintaining the classical way too. IMO, it
> does that to help the programmers, not to "imprision" them. The OOBit
> patch has the same intent: help.
  Ok, I am not against your proposal, but I agree with Gunnar
that you can announce your patch and find users that would like it.
But, I don't feel the need of it.

  Regards,
  Tomás
Reply | Threaded
Open this post in threaded view
|

Re: OOBit

KHMan
In reply to this post by Nilson
On 9/29/2010 9:57 PM, Nilson wrote:

> On Wed, Sep 29, 2010 at 5:03 AM, Gunnar Zötl wrote:
> [snip]
>> So I don't think your proposal is going to make it into the main lua codebase, and as far as I am concerned, that is a good thing.
>>
> I don't know the future of the patch - I already request comments
> about it. (This is a cue to someone be rude - please don´t).
>
>> Nonetheless, make it a lua power patch and put it on the wiki next to the other dotty things, and it will probably find its users.
>>
> I am newbie here. If you read my previous messages, you will see that
> I was asking for comments about the patch before I write it.  I
> thought that I could use this mailing list with this purpose, am I
> wrong?

There is some clear negative pushback. Here is one more, of the
preachy nonsense kind. One big target you painted on yourself is
the big claims on performance increase -- based on instruction
counting, uh, estimating.

On its own, constants is a cute tweak to Lua, as are things like
more explicit OO. But don't over-market it... If you are going to
brag about performance, do some sensible benchmarking. In a
Facebook world, hot air is too cheap to measure these days.

I think they are great as power patches. If anything, it helps to
expand the possibilities with real sample code and benchmark
measurements, rather than speculation. Just don't work on this in
the anticipation that your patches will be hailed as marvels of a
coding god.

I think many new faces here are not yet acquainted with the wisdom
of Antoine de Saint Exupery.

--
Cheers,
Kein-Hong Man (esq.)
Kuala Lumpur, Malaysia

Reply | Threaded
Open this post in threaded view
|

Re: OOBit

Petite Abeille

On Sep 29, 2010, at 7:12 PM, KHMan wrote:

> I think many new faces here are not yet acquainted with the wisdom of Antoine de Saint Exupery.

Kein-Hong Man must undoubtedly have been referring to the following...  

"Grown-ups never understand anything by themselves, and it is tiresome for children to be always and forever explaining things to them" :P


12345