Objection to forced 'object' usage.

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

Objection to forced 'object' usage.

Peter Hill-2
Lua provides some object 'syntactic sugar' allowing methods and such for
those who like them but *until now* has never enforced this OO methodology
on users. The new io library, however, seems to *require* using methods to
read from general files.

I have to say that I don't like this at all, and I also think it is very
un-Lua (which like to keep things basic). It is also rather unnecessary.
The io library could either provide an 'io.fread' command, or allow an
optional file argument to the standard 'io.read'.

*imploringly*
Peter Hill.



Reply | Threaded
Open this post in threaded view
|

RE: Objection to forced 'object' usage.

Peter Prade-2
> Lua provides some object 'syntactic sugar' allowing methods and such for
> those who like them but *until now* has never enforced this OO methodology
> on users. The new io library, however, seems to *require* using methods to
> read from general files.
>
> I have to say that I don't like this at all, and I also think it is very
> un-Lua (which like to keep things basic). It is also rather unnecessary.
> The io library could either provide an 'io.fread' command, or allow an
> optional file argument to the standard 'io.read'.

well i guess you can always do an:
	io.fread = stdin.read

to enable:
	io.fread(filehandle,format1, ...)

if you dislike:
	filehandle:read(format1, ...)

although i cannot understand why? do you want to avoid the additional
operator ":" ?

Cheers,
Peter


Reply | Threaded
Open this post in threaded view
|

Re: Objection to forced 'object' usage.

Peter Hill-2
Peter Hill:
> Lua provides some object 'syntactic sugar' allowing methods and such for
> those who like them but *until now* has never enforced this OO methodology
> on users. The new io library, however, seems to *require* using methods to
> read from general files.
>
> I have to say that I don't like this at all, and I also think it is very
> un-Lua (which like to keep things basic). It is also rather unnecessary.
> The io library could either provide an 'io.fread' command, or allow an
> optional file argument to the standard 'io.read'.

Peter Prade:
> well i guess you can always do an:
> io.fread = stdin.read
>
> to enable:
> io.fread(filehandle,format1, ...)
>
> if you dislike:
> filehandle:read(format1, ...)

Huh? I don't follow this.


> although i cannot understand why? do you want to avoid the additional
> operator ":" ?

Yes. It's not required for any module but this one -- making it a Lua
aberation. I personally rather dislike the "single dispatch" style and I'm
glad that (up until now at least) it has simply been an optional notation
provided for those who take a fancy to it in other languages.

It's just not needed.

Cheers,
Peter Hill.



Reply | Threaded
Open this post in threaded view
|

Re: Objection to forced 'object' usage.

Luiz Henrique de Figueiredo
In reply to this post by Peter Hill-2
Peter Prade:
> well i guess you can always do an:
> io.fread = stdin.read
>
> to enable:
> io.fread(filehandle,format1, ...)
>
> if you dislike:
> filehandle:read(format1, ...)

Peter Hill:
>Huh? I don't follow this.

I guess the stdin stuff mislead you: stdin is just a handy filehandle
that's always available. But once you have any filehandle, you can
do io.fread = filehandle.read and get your function as above. That
filehandle.read is the function you want should be clear from the
definition of ":" as syntax sugar.
--lhf

Reply | Threaded
Open this post in threaded view
|

Re: Objection to forced 'object' usage.

Peter Hill-2
Luiz Henrique de Figueiredo:
> I guess the stdin stuff mislead you: stdin is just a handy filehandle
> that's always available. But once you have any filehandle, you can
> do io.fread = filehandle.read and get your function as above. That
> filehandle.read is the function you want should be clear from the
> definition of ":" as syntax sugar.

So if I have two file handles, "filehandle1" and "filehandle2", is it true
that "filehandle1.read == filehandle2.read"? The manual doesn't specify.

If not then I can't create a general 'fread' from "io.fread =
filehandle1.read". :-(

If it is (and there is actually only ONE file reading function) then why
isn't this single function available as a part of "io"? Why should I have to
open a file before I can find it? =:-O


NOTE:
I don't object to having "filehandle.read" available for those who desire
it... I just want "io.fread" -- or "io.read([<filehandle>,] format etc)" --
also available for those who don't!

Cheers,
Peter Hill.



Reply | Threaded
Open this post in threaded view
|

Re: Objection to forced 'object' usage.

Björn De Meyer
Peter Hill wrote:
> 
> So if I have two file handles, "filehandle1" and "filehandle2", is it true
> that "filehandle1.read == filehandle2.read"? The manual doesn't specify.

Yes, that's right. All filehandle.read refer to the 
same function on creation.  Look at the sources of the lualib,
you'l see for yourself. 

> If it is (and there is actually only ONE file reading function) then why
> isn't this single function available as a part of "io"? Why should I have to
> open a file before I can find it? =:-O

You needn't open a file. As said before, stdin is available as 
a default location for the same function. 


> NOTE:
> I don't object to having "filehandle.read" available for those who desire
> it... I just want "io.fread" -- or "io.read([<filehandle>,] format etc)" --
> also available for those who don't!

We already showed you a way how you can have it. Lua 5 is in feature 
freeze now, anyway, so even if the authors of Lua 
accept your proposal for future versions of Lua, it won't be for 
anytime soon. with only one line of code in your C host, you 
can have what you want.


-- 
"No one knows true heroes, for they speak not of their greatness." -- 
Daniel Remar.
Björn De Meyer 
[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Objection to forced 'object' usage.

marcus.cf
In reply to this post by Peter Hill-2
> io.fread = stdin.read
Is it stdin or io.stdin? The manual says io.stdin. 
Confused...

I also found some undocumented functions in lualib (some 
peole may already know them).

coroutine.status
debug.debug
debug.traceback
io.type
io.popen
rawequal
xpcall
string.dump
string.find
math.pow
lua_pushliteral (API)

Some of them have been commented on the mailing list 
(xpcall, string.dump and others, if I recall correctly), 
but others haven't.

Is there a special reason for the missing documentation 
(apart from lack of time)? I.e.: maybe their names or 
usage could change in Lua 5.0 final?

 
__________________________________________________________________________
E-mail Premium BOL
Antivírus, anti-spam e até 100 MB de espaço. Assine já!
http://email.bol.com.br/



Reply | Threaded
Open this post in threaded view
|

undocumented features

Wim Couwenberg-2
Hi,

marcus.cf:
> I also found some undocumented functions in lualib (some
> peole may already know them).

[... snip snip ...]

There are more undocumented and interesting features (found while doing some
Lua 5.0 experiments):

* __metatable field:  If the metatable of some object contains a
"__metatable" field then the metatable is considered "protected."  This
means that a) you cannot change the metatable of that object (through
setmetatable) and b) a getmetatable call returns the __metatable value.  The
__metatable field does not need to contain a table!

* __globals field:  If the globals table of a function contains a
"__globals" field then the globals table is considered "protected".  This
means that a) you cannot change the globals table of that function (through
setglobals) and b) a getglobals call returns the __globals value.  The
__globals field does not need to contain a table!

Again, maybe these features were left undocumented because they are likely
to change??

Which reminds me: what is the status of the Lua Web Encyclopedia that was
proposed on this list recently?  It would be an excellent place to collect
and document Lua's features.

Bye,
Wim



Reply | Threaded
Open this post in threaded view
|

Re: undocumented features

Roberto Ierusalimschy
> Again, maybe these features were left undocumented because they are likely
> to change??

Most of these features are undocumented due to lack of time. Of course,
this means that most of them are new features, and as such are more
likely to change than older features.

-- Roberto