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

 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");

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

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

 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.

 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