rbSFML

[Laurent]

I don't know how Laurent feels about it but I wouldn't mind if you had SVN access so you could commit it yourself. But if he don't want too many people to have access then I can commit it for you.

I give write access to the SVN to developers who want to maintain a binding in the long term.

So it's up to TricksterGuy to decide:
- if he wants to collaborate in the long term to rbSFML I'll give him SVN access
- if he only wants to submit a few patches then it's better if you review and push them to the repository yourself

[Groogy]

I don't know how Laurent feels about it but I wouldn't mind if you had SVN access so you could commit it yourself. But if he don't want too many people to have access then I can commit it for you.

I give write access to the SVN to developers who want to maintain a binding in the long term.

So it's up to TricksterGuy to decide:
- if he wants to collaborate in the long term to rbSFML I'll give him SVN access
- if he only wants to submit a few patches then it's better if you review and push them to the repository yourself

Aight, well there's a lot left to do which Trickster could help out with if he's up for it. I could create a "ToDo" for rbSFML like you have Laurent to keep track of what needs to be done. There's a lot left to do actually.

I know some "upgrades" we can do to make it more suited for ruby. For instance add a SFML::Input#mouse_position which should return a vector based on the mouse position. Also it would be nice if it was possible to connect vectors so it would be possible to write:

Code: [Select]

sprite = # From somewhere
sprite.position.x = 25 # This would somehow give the sprite position 25


Currently it works like SFML and returns a copy (Well sfml returns a constant reference but you should work with it like a copy). Possible way of doing this would be to create a private "on_change" method to the vector which will look something like this:

Code: [Select]

def on_change  # This is in ruby code but will be implemented in C instead.
  unless @__owner_ref.nil?
    @__owner_ref.send( @__owner_set_method, self )
  end
end

This should get the desired effect and we only need to call it inside SFML::Vector2#x= and SFML::Vector2#y=. Will probably have to add it to SFML::Rect, SFML::Color and to any other class where this would be logically. Also have to add the actual instance variables on every place where we return a copy where we want to be able to change the actual value on the "owner" object. The solution is simple but it's a lot of work.

[Groogy]

Added the SFML::NonCopyable module now. If you mixin this module to your class then it will act as the normal sf::NonCopyable class and override so you can't copy any instances from the class including the module.

I will make every class that is NonCopyable in the C++ library non copyable in rbSFML too now. Also I will have to create my own copy method for some classes like Vector2 and so on.

[Laurent]

Added the SFML::NonCopyable module now

I thought this was very C++-specific. And I thought that in languages such as Ruby, there was no implicit copy ("a = b" is only a "pointer" assignment, both will refer to the same object). And that seems to be true because then you say:

Also I will have to create my own copy method for some classes like Vector2 and so on.

So if you don't provide a copy method for class X, then X is already non-copyable isn't it?

[Groogy]

Added the SFML::NonCopyable module now

I thought this was very C++-specific. And I thought that in languages such as Ruby, there was no implicit copy ("a = b" is only a "pointer" assignment, both will refer to the same object). And that seems to be true because then you say:

Also I will have to create my own copy method for some classes like Vector2 and so on.

So if you don't provide a copy method for class X, then X is already non-copyable isn't it?

Ruby has a "initialize_copy" method which is like the copy constructor in C++. And it's correct, the assignment operator only operates with references but there is a dup and clone method which is provided by default in the Object class in the standard Ruby library. So in order to disable an instance from being copied I have to specifically disable it myself.

When I say I'll have to write those methods myself then it's because of my idea of being able to link the instances of an utility class to an owner instance (like a Vector2 for the position of a Sprite) in order to get a more ruby like environment. But if I would copy that instance then it shouldn't be linked to the owner anymore.

Example:

Code: [Select]


sprite = # From somewhere
sprite.position.x = 25
vector_copy = sprite.position.clone
vector_copy.x = 100
vector_copy == sprite.position # Will evaluate to false since vector_copy is not linked to sprite.


Anyway back to SFML::NonCopyable, I've added it to all concerned classes so now you can't copy for instance a SFML::Window and so on. I don't even want to know what would happen if you tried. Though there are other classes which can be copied which is wrapped around a C++ class, I don't know if I have to write my own initialize_copy method for those in order to get a proper behavior or how Ruby handles it.

[Laurent]

Ruby has a "initialize_copy" method which is like the copy constructor in C++. And it's correct, the assignment operator only operates with references but there is a dup and clone method which is provided by default in the Object class in the standard Ruby library. So in order to disable an instance from being copied I have to specifically disable it myself.

Ok I see

When I say I'll have to write those methods myself then it's because of my idea of being able to link the instances of an utility class to an owner instance (like a Vector2 for the position of a Sprite) in order to get a more ruby like environment. But if I would copy that instance then it shouldn't be linked to the owner anymore.

Ok ok. Is it something that people usually do in Ruby? It looks pretty heavy and complicated.

[Groogy]

When I say I'll have to write those methods myself then it's because of my idea of being able to link the instances of an utility class to an owner instance (like a Vector2 for the position of a Sprite) in order to get a more ruby like environment. But if I would copy that instance then it shouldn't be linked to the owner anymore.

Ok ok. Is it something that people usually do in Ruby? It looks pretty heavy and complicated.

No but I think it would be nice not to have to write:

Code: [Select]

position = sprite.position
position.x = #something
sprite.position = position

When it can be shortened to:

Code: [Select]


sprite.position.x = #something


It's complicated, but not heavy
The only change is one extra method call which would otherwise be called anyway. Why it becomes ruby-like is because you access the vectors as attributes to the instance, and you would expect the change to be applied directly by itself.

[Laurent]

If it's not usual, won't it be confusing? How do other developers deal with this kind of situation?

[Groogy]

If it's not usual, won't it be confusing? How do other developers deal with this kind of situation?

It depends on how the system is designed. I guess you have designed yours so that when we call "SetPosition" on a window it does the proper system calls to emulate that the window position is changed. You could call the position of being a virtual attribute of your sf::Window class. It doesn't really exist for your class but it's emulated from the actual operating systems window as a layer on top of it. An public attribute in Ruby is more or less only method calls on the instance so it's kind of virtual.

But anyway now I see what you mean that it might be confusing. "When is the attribute linked and when is it copied?" It might just be easier for the user to stick with that it's a copy and that you have to explicitly set the attribute to a new value for it to be changed. Also there already is functions like SFML::Drawable#move and so on to fix this easier behaviour for us.

Though the SFML::NonCopyable is still required of course since there are objects that should not be allowed to be cloned/duplicated in ruby. Also I will still have to write specialised initialize_copy methods for those classes that still allow being copied and who are wrapped around a C++ Instance in the SFML library.

[Groogy]

Hmm just wondering, how should I copy a SFML instance? Do you do the same in the assignment operator as you do in the copy constructor? Just wondering if I should do it like this:

Code: [Select]

*object = sf::Clock( *source );
or like this:

Code: [Select]

*object = *source;
when copying your objects. Does it differ between the classes or can I make something generic for every copy-able class?

[Laurent]

Do you do the same in the assignment operator as you do in the copy constructor?

Basically yes. When possible, the assignment operator uses the copy constructor to ensure a consistent behaviour.

Just wondering if I should do it like this:

Code: [Select]

*object = sf::Clock( *source );
or like this:

Code: [Select]

*object = *source;

It's the same, except that the first one performs a useless copy before assignment

Does it differ between the classes or can I make something generic for every copy-able class?

Something generic should be ok.

[Groogy]

Do you do the same in the assignment operator as you do in the copy constructor?

Basically yes. When possible, the assignment operator uses the copy constructor to ensure a consistent behaviour.

Just wondering if I should do it like this:

Code: [Select]

*object = sf::Clock( *source );
or like this:

Code: [Select]

*object = *source;

It's the same, except that the first one performs a useless copy before assignment

Does it differ between the classes or can I make something generic for every copy-able class?

Something generic should be ok.

Nice! I guessed it would be something like that so already using the assignment operator and have already committed the code Though I'm at my home computer so I can't test if it works but it should. Next up to fix is what Trickster wanted, so that providing an string to for instance an image when creating it will implicitly call #loadFromFile and so on.

[Laurent]

Next up to fix is what Trickster wanted, so that providing an string to for instance an image when creating it will implicitly call #loadFromFile and so on.

We had the same discussion for Python and .Net. Basically, creating an empty object (image, sound or whatever) and then calling LoadFromBlop doesn't make sense in such languages where every object is a reference. If you want to load a new image, you can just get a new object instead of reusing the same one. So we chose to remove LoadFromXxx functions and turn them to constructors instead.

[TricksterGuy]

I don't know how Laurent feels about it but I wouldn't mind if you had SVN access so you could commit it yourself. But if he don't want too many people to have access then I can commit it for you.

I give write access to the SVN to developers who want to maintain a binding in the long term.

So it's up to TricksterGuy to decide:
- if he wants to collaborate in the long term to rbSFML I'll give him SVN access
- if he only wants to submit a few patches then it's better if you review and push them to the repository yourself

I will collaborate in the long term.  I've been here for almost two years now and I am not leaving anytime soon I love sfml

[Laurent]

I will collaborate in the long term. I've been here for almost two years now and I am not leaving anytime soon I love sfml

Glad to hear that
I need to know your sourceforge.net account login.