Ruby namespace?

jessejames

I noticed quite a bit of name space pollution in the Ruby API. What is causing this and how do i go about fixing it. I would think that all names within a script would only be available through a script_name.class() syntax, but that is not the case with Ruby -- it seems.

I'll have to explain using Python syntax...

import script
here all names would be accessed by "script.class_or_function_name"

from script import function1, Class1
only "function1" and "Class1" would be available

**from script import ***
any and all names would be imported into name space (this seems to be Ruby's only way)

these 3 options help keep pollution to a minimum or non-existent. What is the equivalent in Ruby? Methods seem to be strung around everywhere and it's quite aggravating when calling obj.methods or obj.private_methods

azuby

You can use modules.

module YourNameSpace
  class YourClass
    # ...
  end
end

YourNameSpace;;YourClass.new

Modules are used in two different ways: 1. to build namespaces, 2. to build mix-ins.

azuby

Jim

@jessejames said:

I noticed quite a bit of name space pollution in the Ruby API.

What prompted that statement?

thomthom

I always warp my code in modules. Only use classes if I need an object. (classes still wrapped in the main project module) But looking at other scripts it looks like people use classes where I use modules. Is there any pros or cons here? Thinking of good practices and code pollution.

Ruby is new to me. I come from PHP, JS, and Visual Basic. (A little bit C#, but probably know Ruby better already).

jessejames

@jim said:

@jessejames said:

I noticed quite a bit of name space pollution in the Ruby API.

What prompted that statement?

I noticed when i do obj.methods, and obj.private_methods, there is a lot of pollution in there. Names that obviously don't belong to that obj.

Python's handles this by making every script you write it's own module(the modulename is the actual file name). Depending on how you import, the names will be available in different forms, like i stated above. I believe this is a beautiful way of handling name space, and everything about Python is just beautiful! Sorry Ruby lovers .

I think SU would benefit greatly from a Python API. Python's simplistic elegance and common sense approach to programming just can't be beat! And you throw out that redundant end statement forever!

Python code is very pleasing to the eye, and very kind to your fingers.

here's your Ruby code....


module YourNameSpace
  class YourClass
    # ...
  end
end
YourNameSpace;;YourClass.new

heres the same Python code...


class YourClass;
    pass

That's it! no ugly end statment, no need to declare a module, just save the script and the modules name will be the file name. I could show you so much more. If you have never checked out Python i urge you to go to http://www.python.org, downoad 2.6 -- if you need help shoot me a message!

Jim

@jessejames said:

I noticed when i do obj.methods, and obj.private_methods, there is a lot of pollution in there. Names that obviously don't belong to that obj.

I wouldn't call it pollution. You're seeing all the methods that the object has. Some of them are inherited, some are class methods, others are instance methods. I suspect what you expected to see were only the instance methods of a class.


Sketchup;;Edge.instance_methods(false)
["other_vertex", "split", "used_by?", "end", "explode_curve", "faces", "soft=", "smooth?", "curve", "find_faces", "length", "all_connected", "start", "line", "common_face", "smooth=", "reversed_in?", "vertices", "soft?"]

azuby

Please, please - no pros and cons between Ruby and Python. It would become a neverending thread. Ruby isn't file oriented and you can define your namespace (or mix-in) in more than one file.

Example to explain mix-ins:

class Light
  # ...
end

l = Light.new
l.switch rescue puts "Light#switch is not implemented"
# => "Light#switch is not implemented"

module Switchable
  def switch
    puts "Switching ..."
  end
end

class Light
  include Switchable
end

l.switch rescue puts "Light#switch is not implemented"
# => "Switching"

# ... and the other way round;
class Light
  undef ;switch
end

l.switch rescue puts "Light#switch is not implemented"
# => "Light#switch is not implemented"

azuby

jessejames

Thanks Jimbo,
I was no aware of the ".instance_methods" method. This will help a lot.

Jim

@jessejames said:

Thanks Jimbo,
I was no aware of the ".instance_methods" method. This will help a lot.

It's hard to find in all the pollution.

jessejames

@azuby said:

Please, please - no pros and cons between Ruby and Python. It would become a neverending thread. Ruby isn't file oriented and you can define your namespace (or mix-in) in more than one file.

I must say it is taking every ounce of energy to keep me from posting a Python version of that light class. My outlaw nature wants to post it -- real bad

azuby

I'm interested in your Python solution. The forum PM function works fine, I think

azuby

jessejames

and so the battle begins....

david.

Not sure why an "end" statement would be considered redundant? I'm not a Ruby fanatic, but it seems a bit premature to dismiss it immediately without fully understanding it...

jessejames

Have you even coded Ruby before? Do you understand what you are saying. If you mean to say that i am no Ruby Guru, then yes, you are right. But i know enough about languages to call Ruby out on some of it's asinine behaviors. My argument about the end statement is as follows...

Why use indentation AND the end statement at the same time? This is like putting two periods at the end of every sentence.. In any high level language today indentation should be standard. Braces, Lisps, and "end" statements are for low level languages. Put the burden on the machine, NOT on me! Python forged the path and showed everybody the way. Ruby can follow this path to it's great destiny or wander off into obscurity.

python code...


def function(arg1, arg2, arg3);
    if this;
        #...
    elif this;
       #...
    else;
       #...

Ruby code...


def function arg1 arg2 arg3
    if this
        #...
    elsif this
        #...
    else
        #...
    end
end

Python's way is clearly better. No need for an end statement. Python also forces parenthesis whether or not an argument is passed/expected. I believe this is where extra typing is justified. I can't tell you how many times i have to make multiple passes on a ruby script to visually parse the script. The "(" and ")" catch your eye and draw you in.

david.

@jessejames said:

Have you even coded Ruby before? Do you understand what you are saying. If you mean to say that i am no Ruby Guru, then yes, you are right. But i know enough about languages to call Ruby out on some of it's asinine behaviors. My argument about the end statement is as follows...

No need to get over-sensitive about this. Apparently, I've coded Ruby enough to know how it handles namespaces. Your original question implied you hadn't researched enough to understand it yourself. It would be pointless to get into debates on Ruby vs. Python vs. ... many of these issues come down to personal preference. Now days, it seems there are about as many programming languages as there are programmers. Your comments about readability when using "(...)" could be just as well applied to the "end" statement. BTW, I personally dislike Ruby's optional use of paren's, but I also like the readability of an end statement (not everyone uses good indentation practices, etc).

Ruby is the SU programming API, so until that changes, it makes more sense to learn what Ruby can do versus complaining about how bad it is compared to some other language.

jessejames

I see what you are saying, we can't just change something as important as the API because some person say's "hey this language is better or that language is better".

But what is the target audience for the SU Ruby API(or any API for that matter?) -- It is SU modelers, NOT professional programmers(although i am sure a few exist here). They need a language that is easy to learn, powerful, widely known, has a future, and most importantly has tons of good documentation. I think anybody (that actually knows Python and Ruby) will hands down agree that Python meets all these standards "ESPECIALLY" documentation. There are so many good tuts across the net that you would have to be blind not to find one. Python is easier to learn and will increase productivity. I am sorry but not only are the API docs lacking ,this poor amount of documentation extends into the world of Ruby. I have yet to find a GOOD, complete Ruby tutorial for non-programmers.

There exists now in the world of high-level languages only two big boys -- Python and Ruby. As far as i am concerned Python is the better of the two if learnability, and readability are your main concerns. I think Python is simplistic programming elegance! As Guido puts it. "Python is less footprint on the brain". I believe if you are an experienced Perl coder you will love Ruby, else you will find it quite confusing.

One of the really great things about Python is the support for true procedural style coding. Ruby's scoping rules won't allow true procedural code without using instance vars. A new programming student quest will be much less painless if they can start with a procedural style and ease into OOP (IMO). I love OOP, but trying to grasp OOP and general programming semantics at the same time can be quite painful. Not to mention that not every problem warrants the use of OOP's machinery, a lot of times OOP can be complete overkill.

Listen, if Ruby where the better language i would happily jump on the Ruby bandwagon and preach to the masses, but IMHO, Python is truly a better choice for any API.

I am not here to just run my mouth, i quite intend to back it up. I would like to have a "Pepsi Challenge" between Python and Ruby using non-programmers. I believe if given the option most (80% or more) would gravitate to Python. Anybody want to accept this challenge?

jessejames

@david. said:

[snip] ...Your comments about readability when using "(...)" could be just as well applied to the "end" statement. BTW, I personally dislike Ruby's optional use of paren's, but I also like the readability of an end statement (not everyone uses good indentation practices, etc).
[snip]

Python forces indentation, so you would never have to worry about poorly indented code. Now your reasoning for keeping the end statement falls completely apart.

ps: Don't let the Gun and wanted poster fool you, i am a very easy going person

driven

@jessejames said:

ps: Don't let the Gun and wanted poster fool you, i am a very easy going person

are you easy going enough to have a look at SuPy and see why SU7.1 won't load the python bundle

301 Moved Permanently

(www.cosc.canterbury.ac.nz)

I don't know anything about scripting, I but need to use this hypocycloid.txt py script in SU,

I can't get SuPy to work and don't know ruby or python to convert it...

or anyone else have any ideas

john

MartinRinehart

There's a lot to be said for Ruby. However, I do think that Python's suites (just indent, no "end" or "}" needed) are an elegant solution for blocking code.

Jim

Is there a way to get a reference to this anonymous namespace crated by load?

I'd like to do something like this:

anon_namespace = load ( "/path/to/command.rb", true )
menu.add_item(anon_namespace.text) { anon_namespace.command }