http://d.puremagic.com/issues/show_bug.cgi?id=2370





------- Comment #10 from terranium@yandex.ru  2008-10-09 07:06 -------
(In reply to comment #0)

why do you think that code working for d2 will work for d3?


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=2370


snake.scaly@gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |alan@akbkhome.com




------- Comment #11 from snake.scaly@gmail.com  2008-10-09 07:22 -------
(In reply to comment #10)
> (In reply to comment #0)
> why do you think that code working for d2 will work for d3?

It's my best guess that D3 will likely support D2 way of doing things rather than D1, if at all.  If I'm wrong I'll fix my version statement to support whatever D3 requires.  But if I'm right I won't be needing to change anything.

Note that D version is only an example.  This sort of version compatibility is required when you need to support multiple versions of a library or a host application.  If I write a plug-in for 3dsmax that must support versions 8, 9, 2008, 2009 and as many future versions as possible, and I know that a particular API is only available from 9 onwards, I put its use under version(max,9) and hope that 2010 will support it as well.


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=2370





------- Comment #12 from brunodomedeiros+bugz@gmail.com  2008-10-15 09:57 -------
(In reply to comment #7)
> (In reply to comment #6)
> > If you add a specific feature in a given version, it's best (clearer) to add a:
> >   version = NiftyMyLibCallAvailable;
> > and then use:
> >   version(NiftyMyLibCallAvailable)
> >   {
> >     NiftyMyLibCall();
> >   }
> > instead of version numbers.
> Is there *any* library around that has a version/#define for every single interface and every single change in that interface?  I don't think so, it's just not feasible.

I've seen the equivalent, in Java. Namely in Eclipse, where the API is managed
through the use of interfaces. Whenever new functionality is added, they don't
changed the existing interface, but add a new one, with a name like
IFooExtension4 Example:
http://help.eclipse.org/stable/index.jsp?topic=/org.eclipse.platform.doc.isv/reference/api/org/eclipse/jface/text/ITextViewerExtension7.html
There are dozens of interfaces like that. (although few reach as many as a 7th
version)

(In reply to comment #8)
> Several of the comments seem to be forgetting that "version = bob" in an imported file has no effect on "version(bob)" statements in the importing file.

Dang, forgot about that indeed.

(In reply to comment #9)
> (In reply to comment #8)
> > Several of the comments seem to be forgetting that "version = bob" in an imported file has no effect on "version(bob)" statements in the importing file.
> You're right.  This is a very strange and undocumented behavior.  Well, this adds more value to my proposal: writing 21 version statements in command line is... well, tedious.

If you use a proper build tool, editor, or IDE (which you obviously should), you should only have to write these statements *once*, which hardly counts as tedious or even significant.


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=2370





------- Comment #13 from brunodomedeiros+bugz@gmail.com  2008-10-15 10:12 -------
(In reply to comment #8)
> Several of the comments seem to be forgetting that "version = bob" in an imported file has no effect on "version(bob)" statements in the importing file.
> 

In fact, I think this fact alone shows that D's version statement mechanism should not be used for version management of user libraries, but only runtime related aspects (the platform/CPU, the compiler, the D version, etc.)

For user libraries, I would suggestion using (manifest) constants to define the lib version, and users of you library could use static if to perform tasks depending on the existing version (including compile-time duck typing like code). Example:

  static if(OpenGL.VersionMajor == 2) {
    ...

  static if(is(com.foo.MyLib.myXptoFunc)) { // check if myXptoFunc is available
    ...


-- 

I don't see a point in continuing to spam bugzilla, so I'll answer here.

> ------- Comment #12 from brunodomedeiros+bugz@gmail.com  2008-10-15 09:57 -------
> (In reply to comment #7)
> > (In reply to comment #6)
> > > If you add a specific feature in a given version, it's best (clearer) to add a:
> > >   version = NiftyMyLibCallAvailable;
> > > and then use:
> > >   version(NiftyMyLibCallAvailable)
> > >   {
> > >     NiftyMyLibCall();
> > >   }
> > > instead of version numbers.
> > Is there *any* library around that has a version/#define for every single interface and every single change in that interface?  I don't think so, it's just not feasible.
> 
> I've seen the equivalent, in Java. Namely in Eclipse, where the API is managed
> through the use of interfaces. Whenever new functionality is added, they don't
> changed the existing interface, but add a new one, with a name like
> IFooExtension4 Example:
> http://help.eclipse.org/stable/index.jsp?topic=/org.eclipse.platform.doc.isv/reference/api/org/eclipse/jface/text/ITextViewerExtension7.html
> There are dozens of interfaces like that. (although few reach as many as a 7th
> version)

It's not the same as defining a separate version statement for every feature, especially when there's nowhere to define them.

I think this solution can be applied to D directly, with either run-time or compile-time checks for available interfaces.  But this approach doesn't seem to be widely adopted and I believe there are reasons behind it.  For instance, I don't want to check all and every interface in my code and support workarounds and fallbacks.  I want to use a specific interface subset available in a particular library version.  If later I want to use a particular cool feature from a newer version then it doesn't quite matter whether it is implemented via versions or interfaces, but if I want *all* the cool stuff I probably don't want to mess with all the interface details again.  I simply use the older code if all the cool features are not available.

It's a matter of usage patterns, and I don't think many developers want to support any combination of features provided by a library.

> (In reply to comment #9)
> > (In reply to comment #8)
> > > Several of the comments seem to be forgetting that "version = bob" in an imported file has no effect on "version(bob)" statements in the importing file.
> > You're right.  This is a very strange and undocumented behavior.  Well, this adds more value to my proposal: writing 21 version statements in command line is... well, tedious.
> 
> If you use a proper build tool, editor, or IDE (which you obviously should), you should only have to write these statements *once*, which hardly counts as tedious or even significant.

I use whatever I want.  And I tend not to use IDEs unless I'm forced to. Anyway, should I write these statements "once" for every Hello World?  Or for every library I attach to my hypothetical IDE?  The result should be a bunch of version statements for every library I use in my project.  How do they get there?