From: ptkwt@... (Phil Tomson) Date: 2004-01-19T13:10:03+09:00 Subject: Re: Fighting Ruby's bad fame In article <20040118210240.21921.00000154@mb-m22.aol.com>, GGarramuno wrote: >>can you elaborate? Ruby has namespaces defined by modules. >> > >Yes, but not good enough. >Compared to Perl or Python, include is missing the ability of Perl's use or >Python's import command to just bring only certain parts of the module into the >current namespace. >In perl, you can do: > use Module (:func1 :func2); You can do this. Remembering back to my Perl days (a distant, fading memory), I never did this. It was always just 'use Module'. (but that's not to say that being able to limit which functions are brought in isn't useful and often warrented). >and in python: > from Module import :func1, :func2 > >And only those two functions/classes/variables get imported into the current >namespace. Ruby's include seems to be an all or nothing proposition, >unfortunately. Perhaps this warrants an RCR. Right now, Matz is very open to RCR's and he's asking for a lot of them to be submitted for Ruby 2. http://rcrchive.net/ Perhaps there could be optional arguments to require and include so that methods can be listed (as you show above): require "foo", :func1, :func2 include Foo, :func1, :func2 It's probably possible to do something like this now, I'd have to play with it a bit to see what I can come up with. > >>As far as modifying builtin classes goes, we're hearing a lot in >>this thread about how this is a problem. Personally, I don't see it as >>long as you're not redefining predefined methods > >Correct. I do see this as a benefit of ruby, too, but not without some form of >leash in the language to have the ability to keep the addition/modification >local or under the programmer's control. >I've been using ruby for about 1 week & 1/2 and already run into that. I >created String#expand_tabs() function in a module of mine only to find a >similar (but less efficient implementation) of that function in another popular >ruby library. Freezing the class is no use as I WANT to be able to do that for >my own class. >This to me already points out the huge issue of name clashes. In this case, it >is not biggie as both functions do the same, but... it already sent shivers >down my spine. >While you can do such things in perl or python, too; those things are usually >discouraged while in the ruby way, they are not. And as I mentioned before, >the include's of the other languages are better than ruby's as the coder can >load the modifications selectively, too. >Personally I like this phisolophy of ruby, but I NEED to have the ability to >easily keep changes to base classes local to my class or in an easy way to >revert them. This is kind of what David Black's Ruby behaviors does. http://uweb.superlink.net/~dblack/ruby/behaviors/ > >> >>Perhaps, but I've written lots of cross-platform scripts. How hard is it >>to do: >> >> case PLATFORM >> when /win/ >> #do Windows things >> when /nix/ >> #do Unix things >> else >> #whatever >> end > >Well, that's the issue isn't it? What is #whatever? Whatever is whatever else you think your script might run on. Practically speaking, you mainly need to cover: Windows, MacOSX, Linux and *BSD. >Now, better yet, can you tell me how can I distinguish the OS name and version >in ruby, since PLATFORM does not tell me that? >Those are the things missing from libraries and having at least ONE library >where all possible alternatives are listed would be nice. >In the case of perl, this is handled more or less as bad as ruby, but there are >a bunch of libraries that have been tested along the years that have a huge >list of these possibilities for you to learn from. >In the case of python, PLATFORM is much more simplified, as os.name can be only >one of 'posix', 'nt', 'dos', 'os2', 'mac', 'ce' or 'riscos'. No surprises >there and no need for any regex'es. Nothing weird like "i386-win32". But what if new OS's are developed? And how do I distinguish between OSX and OS9 if all I get is 'mac'? Do they have an os.version as well? Given that OS9 and OSX are such different beasts, I don't want them lumped together. PLATFORM is set at compile time in Ruby (as in compile time of the Ruby sources). I suppose it would be nice if there were some way to actually query the OS in such a way as to determine the OS name and version. (perhaps another RCR is in order). How does Python setup the os datastructure? > >> >>This works in vim. I'm not an emacs user, but if they could get it >>working with a vim script, I'm sure it can be done in emacs lisp. > >Yes, I'll take a look at writting an emacs macro for this. But still, >refactoring tools would be much more useful. Sure, but as you say Python and Perl don't have those sorts of tools either. I guess this is one place where static typing make it easier for the editor: it provides some idea about types of variables for refactoring. But consider: Refactoring is already a lot easier in dynamically typed languages like Ruby (or Python or Perl). The FreeRIDE folks are planning some support for refactoring ASAIK. > >> >>http://www.swig.org/Doc1.3/Ruby.html#n19 >> > >Yes, been playing with swig1.3. Like it a lot, but it is missing some needed >stuff for ruby. >For example, ALL #define constants are translated to ruby. Even those that are >invalid ruby constants like those starting with underscores (and there does not >seem to be a way to ignore those, as with methods). I wonder how hard this would be to fix. >There seems no way to have swig automatically expose protected methods, which >is quite needed. >There is no %rubycode available like the %pythoncode directive in python mode >to create additional .rb code files. >And I'm not sure mixin's really can deal with multiple inheritance 100% >properly. Sure, methods are easy. I am concerned more about dealing with >variables (both class and instance), thou, as from my quick glance at it, >modules seem to be somewhat limited in this aspect. Definately some limitations to this method of emulating MI. I'm not sure these differences can ever be completely bridged. Ruby supports single inheritance with mixins, whereas C++ supports multiple inheritance with all of the associated problems that come with it. Swig makes a good attempt to bridge the gap, but of course there will never be a perfect bridge between the two. Phil