Here is my SWIG file (redirect.i) …
%module Embed
%{
#include “redirect.h”
%}
class Redirect {
public:
Redirect();
void repaint();
};
OK… this results in a “redirect_wrap.cpp” file.
problem:
To access this class from ruby, I have to type “Embed::Redirect”.
Can I avoid this first part (“Embed::”) of the name ???
–
Simon Strandgaard
Simon Strandgaard wrote:
To access this class from ruby, I have to type “Embed::Redirect”.
Can I avoid this first part (“Embed::”) of the name ???
Is there some reason you can’t just ‘include’ the module, i.e. instead
of this:
foo = Embed::Redirect.new
do this:
include Embed
foo = Redirect.new
?
Lyle
[snip]
OK… this results in a “redirect_wrap.cpp” file.
problem:
To access this class from ruby, I have to type “Embed::Redirect”.Can I avoid this first part (“Embed::”) of the name ???
Except for Lyle … there does’nt seem to be anyone
around with opinions about this!
For ruby/swig’s sake… say something 
On Fri, 18 Apr 2003 01:27:31 +0200, Simon Strandgaard wrote:
–
Simon
Yes “include” can do it, but… read on
Im working on a embedding-tutorial with some skeleton code.
If someone wants to extend this code with a new class,
then he/she has to write a bunch of code, spread out
over many different files.
Im trying to reduce this number of places where you need
to make changes
Is there some way to tell SWIG that it should NOT
encapsulate the classes in a %module module ???
On Thu, 17 Apr 2003 20:11:30 +0000, Lyle Johnson wrote:
Simon Strandgaard wrote:
To access this class from ruby, I have to type “Embed::Redirect”.
Can I avoid this first part (“Embed::”) of the name ???
Is there some reason you can’t just ‘include’ the module, i.e. instead
of this:foo = Embed::Redirect.newdo this:
include Embed foo = Redirect.new?
–
Simon Strandgaard
Can I avoid this first part (“Embed::”) of the name ???
Except for Lyle … there does’nt seem to be anyone
around with opinions about this!
I don’t mind if you avoid the first part.
Then again, I don’t know how valuable my opinion is, I’m a very
experienced programmer.
–
Daniel Carrera
Graduate Teaching Assistant. Math Dept.
University of Maryland. (301) 405-5137
Missed the first part, but doesn’t
include Embed
a = Redirect.new
do what you expect?
On Thu, Apr 24, 2003 at 09:45:02AM +0900, Simon Strandgaard wrote:
On Fri, 18 Apr 2003 01:27:31 +0200, Simon Strandgaard wrote:
[snip]OK… this results in a “redirect_wrap.cpp” file.
problem:
To access this class from ruby, I have to type “Embed::Redirect”.Can I avoid this first part (“Embed::”) of the name ???
Except for Lyle … there does’nt seem to be anyone
around with opinions about this!
Simon Strandgaard wrote:
To access this class from ruby, I have to type “Embed::Redirect”.
Can I avoid this first part (“Embed::”) of the name ???
Except for Lyle … there does’nt seem to be anyone
around with opinions about this!
Well, it’s not a matter of opinion, it’s just a matter of fact 
No, with SWIG-1.3.19 you cannot wrap classes directly into the global
module. Against my better judgment, I am in the process of adding this
capability to SWIG-1.3.20. In the meantime, I think the only
workaround is to just ‘include’ the Embed module into the global module,
as I suggested earlier.
Simon Strandgaard wrote:
I’m working on a embedding-tutorial with some skeleton code.
If someone wants to extend this code with a new class,
then he/she has to write a bunch of code, spread out
over many different files.I’m trying to reduce this number of places where you need
to make changes
This sounds a little suspicious
Is there some way to tell SWIG that it should NOT
encapsulate the classes in a %module module ???
SWIG 1.3.19 definitely doesn’t support this. I think I could add such an
option if it proves useful but I don’t want to add this feature just
because I know how to do it. The reasons for hiding a module’s classes,
methods and constants in its own namespace are pretty well recognized,
whether you’re talking about Ruby or any other programming language.
Can I see the tutorial, or something that might be a little more
convincing of an argument for adding this?
Simon Strandgaard wrote:
To access this class from ruby, I have to type “Embed::Redirect”.
Can I avoid this first part (“Embed::”) of the name ???
Except for Lyle … there does’nt seem to be anyone
around with opinions about this!Well, it’s not a matter of opinion, it’s just a matter of fact
true
No, with SWIG-1.3.19 you cannot wrap classes directly into the global
module. Against my better judgment, I am in the process of adding this
capability to SWIG-1.3.20.
You are the hero of the day
I am really looking forward to 1.3.20…
Thanks
Simon Strandgaard
On Thu, 24 Apr 2003 09:54:16 +0000, Lyle Johnson wrote:
Simon Strandgaard wrote:
I’m working on a embedding-tutorial with some skeleton code.
If someone wants to extend this code with a new class,
then he/she has to write a bunch of code, spread out
over many different files.I’m trying to reduce this number of places where you need
to make changesThis sounds a little suspicious
Admitted: it is possible to join some of the files, but then
it all becomes messy and non-intuitive.
Is there some way to tell SWIG that it should NOT
encapsulate the classes in a %module module ???SWIG 1.3.19 definitely doesn’t support this. I think I could add such an
option if it proves useful but I don’t want to add this feature just
because I know how to do it.
I fully understand… bloating sux
The reasons for hiding a module’s classes,
methods and constants in its own namespace are pretty well recognized,
whether you’re talking about Ruby or any other programming language.
Its a cosmetic detail…
Its fairly intuitive for me. But it adds an extra twist when
I must explain to the tutorial-readers why this is necessary.
Many details => complexity => non-intuitive.
Can I see the tutorial, or something that might be a little more
convincing of an argument for adding this?
http://metaeditor.sourceforge.net/embed/index.html
Take a look at the tar.gz file in the [advanced wrapper] section.
On Thu, 17 Apr 2003 22:10:15 +0000, Lyle Johnson wrote:
–
Simon Strandgaard
I present 2 solutions for the “user”…
(a) how a wrapper looks with SWIG.
(b) how a wrapper looks when you do all wrapping yourself.
Hopefully the user then can feel some visual difference
But in order to get (a) and (b) behaving in exactly the same way,
I must declare (b) under a %module-namespace.
problem: this adds an extra twist to the complexity.
On Fri, 18 Apr 2003 05:41:36 +0200, Simon Strandgaard wrote:
On Thu, 17 Apr 2003 22:10:15 +0000, Lyle Johnson wrote:
Simon Strandgaard wrote:
The reasons for hiding a module’s classes,
methods and constants in its own namespace are pretty well recognized,
whether you’re talking about Ruby or any other programming language.Its a cosmetic detail…
Its fairly intuitive for me. But it adds an extra twist when
I must explain to the tutorial-readers why this is necessary.Many details => complexity => non-intuitive.
–
Simon Strandgaard