Re: Name for GStreamer bindings
On Sat, 2005-02-26 at 15:14 -0500, Randy W. Sims wrote: That's the question. What do others think? I'd consider it a very bad practice. Imagine if many authors started doing the same. There could be unpredictable collisions all over the place. It defeats the CPAN scheme for ensuring unique namespaces. That's a problem indeed. I still don't see the problem of using a proper namespace. Arguments of length are not compelling. What's wrong with a descriptive name? I tried to explain this two times already. If it doesn't convince you, well, there's nothing more I can do. If you had ever used a module such as Gtk2 or Gnome2, you'd understand. -- Bye, -Torsten
Re: Name for GStreamer bindings
On Fri, 2005-02-25 at 09:43 +0100, A. Pagaltzis wrote: use constant Gst='Multimedia::Gstreamer'; Gst-new(); I just realized that this won't work. I don't just need Gst to be an alias for Media::GStreamer, I need Gst::* to be an alias for Media::GStreamer::*. That also seems to rule out the aliased.pm approach. Why? Sure, you need many constants, not just one, but does that matter? No, not really. It seems a bit cumbersome, but I guess it would work. Something that doesn't seem to have come up in debate here is that the distribution and main module namespace need not dictate the package names for classes. You could well stick everything in Gst:: even though your modules are called Media::GStreamer(::.*)?. This sounds very evil, but might actually work! This would solve the problem in a pretty elegant way: No top-level CPAN pollution, but a usable namespace. Is this a bad idea even if it's clearly documentent? That's the question. What do others think? -- Bye, -Torsten
Re: Name for GStreamer bindings
Torsten Schoenfeld wrote: On Fri, 2005-02-25 at 09:43 +0100, A. Pagaltzis wrote: use constant Gst='Multimedia::Gstreamer'; Gst-new(); I just realized that this won't work. I don't just need Gst to be an alias for Media::GStreamer, I need Gst::* to be an alias for Media::GStreamer::*. That also seems to rule out the aliased.pm approach. Why? Sure, you need many constants, not just one, but does that matter? No, not really. It seems a bit cumbersome, but I guess it would work. Something that doesn't seem to have come up in debate here is that the distribution and main module namespace need not dictate the package names for classes. You could well stick everything in Gst:: even though your modules are called Media::GStreamer(::.*)?. This sounds very evil, but might actually work! This would solve the problem in a pretty elegant way: No top-level CPAN pollution, but a usable namespace. Is this a bad idea even if it's clearly documentent? That's the question. What do others think? I'd consider it a very bad practice. Imagine if many authors started doing the same. There could be unpredictable collisions all over the place. It defeats the CPAN scheme for ensuring unique namespaces. I still don't see the problem of using a proper namespace. Arguments of length are not compelling. What's wrong with a descriptive name? The name Gst means nothing to most people. It's fortunate that not all authors have the view that modules interfaced to external libs get their own TLN. There are some bad examples out there, but for each there is a good counter example, eg XML::LibXML. Randy.
Re: Name for GStreamer bindings
* Torsten Schoenfeld [EMAIL PROTECTED] [2005-02-26 19:25]:
Is this a bad idea even if it's clearly documentent?
That's the question. What do others think?
Thinking about it, I can see one objection: it might increase the
probability of a clash with a future module trying to use the
Gst TLNS if the label doesn't appear in your filenames. Of
course the question is: is that a real problem?
Regards,
--
#Aristotle
*AUTOLOAD=*_=sub{s/(.*)::(.*)/print$2,(,$\/, )[defined wantarray]/e;$1};
Just-another-Perl-hacker;
Re: Name for GStreamer bindings
* Torsten Schoenfeld [EMAIL PROTECTED] [2005-02-24 18:15]:
use constant Gst='Multimedia::Gstreamer';
Gst-new();
I just realized that this won't work. I don't just need Gst to
be an alias for Media::GStreamer, I need Gst::* to be an alias
for Media::GStreamer::*. That also seems to rule out the
aliased.pm approach.
Why? Sure, you need many constants, not just one, but does that
matter?
Something that doesn't seem to have come up in debate here is
that the distribution and main module namespace need not dictate
the package names for classes. You could well stick everything in
Gst:: even though your modules are called Media::GStreamer(::.*)?.
Is this a bad idea even if it's clearly documentent?
Regards,
--
#Aristotle
*AUTOLOAD=*_=sub{s/(.*)::(.*)/print$2,(,$\/, )[defined wantarray]/e;$1};
Just-another-Perl-hacker;
Re: Name for GStreamer bindings
On Wed, 2005-02-23 at 18:55 +, Orton, Yves wrote:
I tried to explain that in my original mail. The GStreame bindings,
just like Gtk2 or Gnome2, are different. You don't just use one
constructor once. Typical applications will have to create many
Gst::Element's, a few Gst::Structure's, some Gst::Index's,
Gst::Caps's, a Gst::Clock, etc., etc. Try imagining how long this
paragraph would be if I used Multimedia::GStreamer as the namespace.
Export a constant Gst() that equals Multimedia::Gstreamer.
Ie the moral equivelent of
use constant Gst='Multimedia::Gstreamer';
Gst-new();
I just realized that this won't work. I don't just need Gst to be an
alias for Media::GStreamer, I need Gst::* to be an alias for
Media::GStreamer::*. That also seems to rule out the aliased.pm
approach.
Or make a factory sub:
sub GstNew {
my $class=Multimeadia::Gstreamer::.shift(@_);
return $class-new(@_);
}
And also possibly a clone method:
my $elem=GstNew(Clock);
my $other_elem=$elem-clone();
That would work, but seems way too hacky to me. It would also deviate
quite a bit from the C API, which I want to avoid. Thanks for the
suggestion nonetheless, though.
--
Bye,
-Torsten
Re: Name for GStreamer bindings
On Tue, Feb 22, 2005 at 09:20:19PM -0500, Kevin C. Krinke wrote: On Wed, 2005-02-23 at 01:20 +0100, Torsten Schoenfeld wrote: Aloha, GStreamer is a powerful and pretty popular media framework. GNOME already uses it extensively, and KDE just started to. It's based on GLib and uses its object oriented C API style. The objects have names like GstQueue or GstElement. ... Gnome2::Gst:: makes sense to me. Except it's not tied to Gnome. KDE users it too. One option would be to use a very clear top level name space and used 'aliased' internally to call it 'Gst'. http://search.cpan.org/~ovid/aliased-0.11/lib/aliased.pm Mark
Re: Name for GStreamer bindings
Mark Stosberg wrote: On Tue, Feb 22, 2005 at 09:20:19PM -0500, Kevin C. Krinke wrote: On Wed, 2005-02-23 at 01:20 +0100, Torsten Schoenfeld wrote: Aloha, GStreamer is a powerful and pretty popular media framework. GNOME already uses it extensively, and KDE just started to. It's based on GLib and uses its object oriented C API style. The objects have names like GstQueue or GstElement. ... Gnome2::Gst:: makes sense to me. Except it's not tied to Gnome. KDE users it too. One option would be to use a very clear top level name space and used 'aliased' internally to call it 'Gst'. http://search.cpan.org/~ovid/aliased-0.11/lib/aliased.pm Another alternative is to let the user choose. Take a look at Yves' Data::Dumper::Streamer module. During the installation, the user has a choice of additionally installing it in the DDS namespace (this does not occur by default). http://search.cpan.org/~yves/Data-Dump-Streamer-1.10/lib/Data/Dump/Streamer.pm#Installing_DDS_as_an_alias (unwrap as required). David
Re: Name for GStreamer bindings
On Wed, 2005-02-23 at 14:08 +0100, David Landgren wrote: Another alternative is to let the user choose. Take a look at Yves' Data::Dumper::Streamer module. During the installation, the user has a choice of additionally installing it in the DDS namespace (this does not occur by default). That doesn't sound like a good idea to me. Application writers couldn't be sure if they can use the short version of the package name, since it's up to the user/package if it gets enabled. -- Bye, -Torsten
Re: Name for GStreamer bindings
On Wed, 2005-02-23 at 00:26 -0500, Randy W. Sims wrote: Multimedia::GStreamer What about just using Media::GStreamer and aliasing it to Gst? That would introduce a new top-level namespace, but I think it makes sense to have it. I don't see any advantage of using Gst over GStreamer as a name, they both describe the same thing and GStreamer is a tad more helpfull (to google a description). It's all about the length. I need something that is easy and fast to type. Then Gnome part as mentioned seems irrelevant. Glib is possibly usefull info, but probably better conveyed via documentation as an implementation issue. Agreed. It might be nice to say somethnig about what it does: plugin, pipeline... I can't think of a better word. Well, that's just an implementation detail too, isn't it? -- Bye, -Torsten
RE: Name for GStreamer bindings
Title: RE: Name for GStreamer bindings On Wed, 2005-02-23 at 14:08 +0100, David Landgren wrote: Another alternative is to let the user choose. Take a look at Yves' Data::Dumper::Streamer module. During the installation, the user has a choice of additionally installing it in the DDS namespace (this does not occur by default). That doesn't sound like a good idea to me. Application writers couldn't be sure if they can use the short version of the package name, since it's up to the user/package if it gets enabled. Except that application writers shouldn't give a toss about how long a modules name is. Somebody writing one liners or quick snippet might have a case but anybody writing maintainable code doesn't. The point of the DDS alias is so you can say: perl -MDDS -eDump(bless qr/oh my god!/,'ARRAY') Not really so that you can say use DDS; Cheers Yves
Re: Name for GStreamer bindings
Torsten Schoenfeld writes: On Wed, 2005-02-23 at 00:26 -0500, Randy W. Sims wrote: I don't see any advantage of using Gst over GStreamer as a name, they both describe the same thing and GStreamer is a tad more helpfull (to google a description). It's all about the length. It always is. Obviously everybody would prefer the modules that they use frequently to have the shortest possible names. The trouble with that is we all work with different things in our daily lives, and abbreviations which are customary in a particular field are unfathomable to those outside the field -- indeed, it's often not even possible to work out what the field is. If all modules have really short names then nobody knows when anybody else's modules are for, which rather defeats the purpose of Cpan. Cpan is a global namespace, and as such names have to be chosen carefully to be as meaningful as possible to people who don't share the author's context. I need something that is easy and fast to type. Why? I can see why you'd _like_ something that's less to type, but why is there a need that applies to this module rather than other modules. You only have to type the module name in the use line and in any class methods, often just a constructor. GST can mean many things (try Googling for it) -- even within the context of Gnome it has another meaning: http://www.gnome.org/projects/gst/ Smylers
Re: Name for GStreamer bindings
On Wed, 2005-02-23 at 18:25 +, Smylers wrote: If all modules have really short names then nobody knows when anybody else's modules are for, which rather defeats the purpose of Cpan. Cpan is a global namespace, and as such names have to be chosen carefully to be as meaningful as possible to people who don't share the author's context. Yeah, I agree. That's why I like Mark's proposal of using aliased.pm to alias something like Media::GStreamer to Gst. I need something that is easy and fast to type. Why? I can see why you'd _like_ something that's less to type, but why is there a need that applies to this module rather than other modules. You only have to type the module name in the use line and in any class methods, often just a constructor. I tried to explain that in my original mail. The GStreamer bindings, just like Gtk2 or Gnome2, are different. You don't just use one constructor once. Typical applications will have to create many Gst::Element's, a few Gst::Structure's, some Gst::Index's, Gst::Caps's, a Gst::Clock, etc., etc. Try imagining how long this paragraph would be if I used Multimedia::GStreamer as the namespace. GST can mean many things (try Googling for it) -- even within the context of Gnome it has another meaning: It's the object prefix the library itself uses, and also has other precedents. -- Bye, -Torsten
RE: Name for GStreamer bindings
Title: RE: Name for GStreamer bindings
If all modules have really short names then nobody knows
when anybody
else's modules are for, which rather defeats the purpose of
Cpan. Cpan
is a global namespace, and as such names have to be chosen
carefully to
be as meaningful as possible to people who don't share the author's
context.
Yeah, I agree. That's why I like Mark's proposal of using
aliased.pm to
alias something like Media::GStreamer to Gst.
I need something that is easy and fast to type.
Why? I can see why you'd _like_ something that's less to
type, but why
is there a need that applies to this module rather than
other modules.
You only have to type the module name in the use line and
in any class
methods, often just a constructor.
I tried to explain that in my original mail. The GStreamer bindings,
just like Gtk2 or Gnome2, are different. You don't just use one
constructor once. Typical applications will have to create many
Gst::Element's, a few Gst::Structure's, some Gst::Index's,
Gst::Caps's,
a Gst::Clock, etc., etc. Try imagining how long this
paragraph would be
if I used Multimedia::GStreamer as the namespace.
Export a constant Gst() that equals Multimedia::Gstreamer.
Ie the moral equivelent of
use constant Gst='Multimedia::Gstreamer';
Gst-new();
Or make a factory sub:
sub GstNew {
my $class=Multimeadia::Gstreamer::.shift(@_);
return $class-new(@_);
}
And also possibly a clone method:
my $elem=GstNew(Clock);
my $other_elem=$elem-clone();
Yves
Name for GStreamer bindings
Aloha, GStreamer is a powerful and pretty popular media framework. GNOME already uses it extensively, and KDE just started to. It's based on GLib and uses its object oriented C API style. The objects have names like GstQueue or GstElement. For similar objects like GtkWindow or GnomeIconList in other libraries, us Gtk2-Perl people tend to directly map them to namespaces: Gtk2::Window and Gnome2::IconList. For smaller libraries like libwnck or librsvg, on the other hand, we try not to pollute the top-level namespace: Gnome2::Wnck::Screen, Gnome2::Rsvg::Handle, etc. For GStreamer, I would tend towards using Gst as a namespace. It matches the C objects' names. It's short to type, which is not unimportant since it's not like the typical Perl OO module where the full package name only appears once when using the constructor -- the GStreamer bindings contain a lot of objects with their own constructors, many of which almost all programs will use. It's not directly GNOME-related. And lastly, Gst has a precedent: the Python bindings also use this namespace. On the con side, there's of course the introduction of a new top-level namespace. One that is an abbreviation and not easily recognizable. So, if you were to write Perl bindings for GStreamer, what namespace would you use? -- Thanks, -Torsten
Re: Name for GStreamer bindings
On Wed, 2005-02-23 at 01:20 +0100, Torsten Schoenfeld wrote: Aloha, GStreamer is a powerful and pretty popular media framework. GNOME already uses it extensively, and KDE just started to. It's based on GLib and uses its object oriented C API style. The objects have names like GstQueue or GstElement. For similar objects like GtkWindow or GnomeIconList in other libraries, us Gtk2-Perl people tend to directly map them to namespaces: Gtk2::Window and Gnome2::IconList. For smaller libraries like libwnck or librsvg, on the other hand, we try not to pollute the top-level namespace: Gnome2::Wnck::Screen, Gnome2::Rsvg::Handle, etc. For GStreamer, I would tend towards using Gst as a namespace. It matches the C objects' names. It's short to type, which is not unimportant since it's not like the typical Perl OO module where the full package name only appears once when using the constructor -- the GStreamer bindings contain a lot of objects with their own constructors, many of which almost all programs will use. It's not directly GNOME-related. And lastly, Gst has a precedent: the Python bindings also use this namespace. On the con side, there's of course the introduction of a new top-level namespace. One that is an abbreviation and not easily recognizable. So, if you were to write Perl bindings for GStreamer, what namespace would you use? Gnome2::Gst:: makes sense to me. -- Kevin C. Krinke [EMAIL PROTECTED] Open Door Software Inc.
Re: Name for GStreamer bindings
Torsten Schoenfeld wrote: Aloha, GStreamer is a powerful and pretty popular media framework. GNOME already uses it extensively, and KDE just started to. It's based on GLib and uses its object oriented C API style. The objects have names like GstQueue or GstElement. For similar objects like GtkWindow or GnomeIconList in other libraries, us Gtk2-Perl people tend to directly map them to namespaces: Gtk2::Window and Gnome2::IconList. For smaller libraries like libwnck or librsvg, on the other hand, we try not to pollute the top-level namespace: Gnome2::Wnck::Screen, Gnome2::Rsvg::Handle, etc. For GStreamer, I would tend towards using Gst as a namespace. It matches the C objects' names. It's short to type, which is not unimportant since it's not like the typical Perl OO module where the full package name only appears once when using the constructor -- the GStreamer bindings contain a lot of objects with their own constructors, many of which almost all programs will use. It's not directly GNOME-related. And lastly, Gst has a precedent: the Python bindings also use this namespace. On the con side, there's of course the introduction of a new top-level namespace. One that is an abbreviation and not easily recognizable. So, if you were to write Perl bindings for GStreamer, what namespace would you use? Multimedia::GStreamer I don't see any advantage of using Gst over GStreamer as a name, they both describe the same thing and GStreamer is a tad more helpfull (to google a description). Then Gnome part as mentioned seems irrelevant. Glib is possibly usefull info, but probably better conveyed via documentation as an implementation issue. It might be nice to say somethnig about what it does: plugin, pipeline... I can't think of a better word. Multimedia::Pipeline::GStreamer ??? Randy.
