www.digitalmars.com         C & C++   DMDScript  

D - Module versioning

reply Juarez Rudsatz <juarezNOSPAM correio.com> writes:
I know you tired of people sending post like "I have a new wonderfull idea. 
Bla, bla, bla". And I know D already has too much features.
But take a look in this wonderfull, killer, amazing and powerfull feature:     
:-)

MODULE VERSIONING

1 - Floating number representation

At lexical level a new representation of float literals is useful for many 
task including version numbers, tcp/ip numbers. It can be writed as:

    	float f = 1.25.4.0
    	float ip = 128.0.0.1

The adittional "." above represent the thousand decimal separator. See:

    	1.25.04.0 == 1.250004
    	128.0.0.1 == 128.000000001

2 - Assert contract have a option message describing the problem found

    	assert(int.size == 4, "This code will only run in 32 bits cpus");

3 - Module version

Each module could have a .version property and a .vendor property. They 
will be assigned within the module:

    	module mymod;

    	mymod.version = 1.02.1;
    	mymod.vendor = "Monkey$oft"

And this information could be used in for many reasons:

o    	Minimal implementation

    	import mymod;

    	unittest
    	{
    	    	assert(mymod.version >= 2.01, "You need the new version of that  
module");
    	}

o    	Dealing with buggy code

    	unittest
    	{
    	    	assert(mymod.version != 1.2 && mymod.vendor == "DigitalMars", 
"This version of mymod is buggy :-)"); 
    	}

o    	Adapting the application for diferent version of the same lybrary

    	if (glic.version in (2.1..2.2))
    	{
    	    	adaptForLegacy()
    	} 
    	else 
    	if (glic.version >= 2.3)
    	{
    	    	doTheOptimizedWay();
    	}
    	

o    	Political wars

    	unittest
    	{
    	    	assert(mymod.vendor != "Monkey$oft", "We don't like 
Monkey$oft.");
    	}

4 - Initial values

These properties need to be optional and initialized to:

.version  = nan;
.vendor   = "";

5 - Why not use a const version_id and vendor_name ?

o    	Not all modules will have versioning
o    	There are no standart way to verify what version that module 
implements.
o    	Can support diferent library implementations.


Saudações

Juarez Rudsatz
Mar 11 2003
next sibling parent "Mike Wynn" <mike.wynn l8night.co.uk> writes:
"Juarez Rudsatz" <juarezNOSPAM correio.com> wrote in message
news:Xns933BCB5FD7416juarezcom 63.105.9.61...

 I know you tired of people sending post like "I have a new wonderfull


idea.

 Bla, bla, bla". And I know D already has too much features.
 But take a look in this wonderfull, killer, amazing and powerfull feature:
 :-)

 MODULE VERSIONING

 1 - Floating number representation

 At lexical level a new representation of float literals is useful for many
 task including version numbers, tcp/ip numbers. It can be writed as:

     float f = 1.25.4.0
     float ip = 128.0.0.1
 The adittional "." above represent the thousand decimal separator. See:

     1.25.04.0 == 1.250004
     128.0.0.1 == 128.000000001


it may have escaped you but an ip addresses are 32 bit fixed point numbers
not 1:7:24 floats so you can not use a float to hold an ip address (and v6
are bigger than double or long) if it was not for some merits to the other
sugestions I would have been tempted to think about posting "dont feed the
troll" and then take my own advice.

why not truple's instead of yet another build in specialised type.
I know 2d vectors and complex numbers are different, all though operations
on them do require
similar cpu instructions (magnitude is the the same op)
and complex multiply is close to 2d vector dot and cross
(p,q are complex of the for (a+ib) and (c+id); p', q' are vectors of the
form (a,b) (c,d)
p * conjegate(q) => ( dot(p',q') + i*cross(p',q')) // or somthing close
anyway

ip address is just 4 bytes ( or 4 ints for a v6 (3 ints and 4 bytes for
compatibly with v4)) // don't quote me on that its the idea I'm trying to
get across.




 2 - Assert contract have a option message describing the problem found
     assert(int.size == 4, "This code will only run in 32 bits cpus");


that or having the assert put the condition as a string in the message, so;
assert( int.size == 4); would give "assert failed 'int.size==4' is not true
at line xxxx in File yyyy"


 3 - Module version

 Each module could have a .version property and a .vendor property. They
 will be assigned within the module:


as much as I like the idea, alas it still fails to catch the usual problem
.... you forget to increment your version number.

the only automated solution I can see is allowing modules to be sectioned
each section has its "signature" hashed and that is stored both in the
module and any places it is imported.
adding a new function to a section changes that section (so old code will
not load the module)
adding a new section (without changing the names/params of the modules
classes etc) would allow oldcode to use the original interface (i.e.
original section) and newcode to also call into the new section.
classes and structures could also use this (may be with an included length
field as the first member) to detect the version (as windows does manually
for many structs) and thus the valid sections (append only so layout would
have to be ordered, new section at the end only (new virtual funcs at end of
vtbl etc).



 Mar 11 2003



prev sibling  parent reply "Walter" <walter digitalmars.com>  writes:


Check out www.digitalmars.com/d/version.html



 Mar 13 2003



 next sibling parent reply "Mike Wynn" <mike.wynn l8night.co.uk>  writes:


"Walter" <walter digitalmars.com> wrote in message
news:b4r8co$1ip1$1 digitaldaemon.com...

 Check out www.digitalmars.com/d/version.html


I C its a bit hidden
 version (ProfessionalEdition)
	{
	    version = FeatureA;
	    version = FeatureB;
	    version = FeatureC;
	}

could be

version (version_1_1_3_release)
{
    version = version_1;        // the original interface
    version = version_1_1;   // the bits we added for solve problem x
    version = version_1_1_3;  // the bug fixes to1_1_2 same i/f
}

that's great for building static app, but ... what about import libs do they
contain the version symbols that where used ?



 Mar 13 2003



  parent  "Walter" <walter digitalmars.com>  writes:


"Mike Wynn" <mike.wynn l8night.co.uk> wrote in message
news:b4r963$1j9e$1 digitaldaemon.com...

 that's great for building static app, but ... what about import libs do


they

 contain the version symbols that where used ?


No, they do not. Versioning of imports is probably best accomplished by
appending a version number to the import name, and then using the version
declaration and aliases to pick which version is to be used.



 Mar 24 2003



prev sibling  parent reply "Sean L. Palmer" <seanpalmer directvinternet.com>  writes:


I couldn't find it at first either.  But it looks like a good feature to me.

I'm curious what the scope of those version specifications are though.  The
webpage doesn't say.  My first impulse would be to give them the scope
they're declared in, but it might be nice to be able to export them maybe,
access public ones from other modules perhaps?

Sean

"Walter" <walter digitalmars.com> wrote in message
news:b4r8co$1ip1$1 digitaldaemon.com...

 Check out www.digitalmars.com/d/version.html





 Mar 13 2003



  parent  "Walter" <walter digitalmars.com>  writes:


"Sean L. Palmer" <seanpalmer directvinternet.com> wrote in message
news:b4rsvv$20eh$1 digitaldaemon.com...

 I'm curious what the scope of those version specifications are though.


The

 webpage doesn't say.  My first impulse would be to give them the scope
 they're declared in, but it might be nice to be able to export them maybe,
 access public ones from other modules perhaps?


Their scope is at the module level.



 Mar 24 2003