I pose the question to Slashdot... What reason would a large organization have at this point to run Vista?
Integrated support for disk-image based installation, without the need for third party products. Improved support for policies that allow more detailed management of what users can and can't do with their PCs. Full drive encryption. SoftGrid as part of the Desktop Optimization Pack, allows you to run applications in complete isolation from each other.
All of these are useful technologies for a large organization which are new to Vista (although, admittedly, some of them were previously available from third party suppliers for XP, having them integrated and MS-approved helps such an organization a lot).
By 'create' a tool, they do mean compilers like gcc & fpc, and of course the bash shell, right?
I posted an automated translation of the law in response to Fyodor's thread, above. But the relevant fact is that the "purpose" of the tool must be hacking. So, you'd be pretty safe with these. Fyodor's on a little muddier ground, though.
(1) Who prepares a criminal offence after 202a or 202b, by he 1. Passwords or other safeguard codes, those the entrance to data ( 202a Exp. 2) make possible, or 2. Computer programs, whose purpose is committing such an act, manufactures, or another provided, sold, another leaves themselves, common or makes otherwise accessible, becomes with imprisonment up to one year or also Fine punishes.
I find the idea that this is any worse than the UK law that passed strange:
3A Making, supplying or obtaining articles for use in offence under section 1 or 3 (1) A person is guilty of an offence if he makes, adapts, supplies or offers to supply any article intending it to be used to commit, or to assist in the commission of, an offence under section 1 or 3. (2) A person is guilty of an offence if he supplies or offers to supply any article believing that it is likely to be used to commit, or to assist in the commission of, an offence under section 1 or 3. (3) A person is guilty of an offence if he obtains any article with a view to its being supplied for use to commit, or to assist in the commission of, an offence under section 1 or 3. (4) In this section "article" includes any program or data held in electronic form. (5) A person guilty of an offence under this section shall be liable--
(a) on summary conviction in England and Wales, to imprisonment for a term not exceeding 12 months or to a fine not exceeding the statutory maximum or to both;
(b) on summary conviction in Scotland, to imprisonment for a term not exceeding six months or to a fine not exceeding the statutory maximum or to both;
(c) on conviction on indictment, to imprisonment for a term not exceeding two years or to a fine or to both.
Section (2) is much more general than the German law, requiring only that you believe it likely that the article supplied will be used in such a crime, while the German law requires intent that it be used in such a crime. Plus, the UK law allows 2 years imprisonment, the German law only one.
So, all in all, I'd say you're on much safer grounds visiting Germany than the UK over this one.
I've only ever heard it called meths, even though the spirit is singular.
No, no. The spirit is plural. Go find a bottle, it'll say "methylated spirits" on it. I believe the name derives from the traditional recipe of a mixture of ethanol (a spirit) with methanol (another spirit).
To adequately test business rules expressed in code is entirely possible - but the programmer has to either be a domain expert and psychic to boot or have a very good customer representative who not only actually understands and can communicate their requirements but is capable of verifying that the unit tests truly test those requirements.
Business rules code with a 'why is this here?' comment pretty much guarantee that this is not the case. They indicate a feature that was a rush job for some reason, and the #1 rule of rush jobs is that the only requirement you get is "make this work. Right Now".
Ah, I see your point now. The comment is to explain that the _requirements_ are unclear, not that the code is. That makes some sense.
Still, such a comment wouldn't be in my code. The comment would say something more like "// this is necessary to make TestStupidObject.testThatInexplicableRule34aIsFoll owed pass", which is much clearer: the reason for the _code_ is fully documented. The reason for the test is perhaps unknown, but that's perhaps a little easier for somebody to figure out later.
For the original commenter who mentioned these comments, I don't think this was the case. I'm pretty sure he was talking about code that had been mysteriously added to fix something broken, where he understood what was broken at the time, but just lost track of what the fix was supposed to do later on.
My point is that if there is code to do something, there should be a unit test for it. If you understand the problem enough to write the code, surely you understand it enough to write a test that the code works correctly. I'll grant that you might not understand why the test is necessary, but that's an entirely different matter.
That works on the gross physical level, but suppose removing the 'why is this here?' code works to modify a high level object in such a way that doesn't break anything.
In that case, you don't have adequate unit tests. The key to writing unit tests properly is to make sure that for each code execution path in the application there is at least one test that will fail if you remove that path (or, conversely, using the approach of test driven development: don't implement a code path until there's a test that will show whether or not it worked). If you have followed this rule, then there will not be any code in your system that wouldn't break anything if it wasn't there.
Yes, the canvas tag is in there. It is, of course, already supported by Safari and Mozilla (and Opera, IIRC), and there's a free script that can be used to make IE support it as well, so there's little reason not to start using it already.
A serious question here: what features do you need that aren't covered by simply using 'display: table-cell' and 'display: table-row'?
I can think of a few that might be useful:
* Ability to define column/row orders independently of element order (i.e. something like 'table-cell-column-index:0' to force a cell to appear in the leftmost column, etc.) * Ability to make an element span multiple rows or columns * Regarding text flow in columns, etc., something like 'overflow-target: #nextelement' (need to think about how box sizing works in the presence of text overflowing into the next box)
It is going to take a long time before web developers can take advantages of these tags. We need the browsers to start using it which may take a while. Firefox may jump on first then maybe Safari and others IE will probably take 2-3 more years until it supports HTML 5.
Firefox and Safari have already implemented a lot of this stuff, and some of it is supported in IE already too (even if only by hacks). A good example is the 'canvas' tag. It was implemented in safari before the working group even started, and was implemented by firefox quite soon after it was added to the working draft of the standard. Scripts are available that implement it for IE as well. Other things are standardisations of what were previously IE-proprietary extensions (e.g. the 'contenteditable' system), so are already fully supported by IE, and will likely be available in firefox & safari soon.
A big advantage of XHTML was that the conversion to a parse tree was unambiguous. Why give up that at this late date?
Nobody's giving up on that. One of the goals of HTML5 is to ease adoption of XHTML, for instance by removing details from the HTML specification that are incompatible with XHTML: e.g., in the description of parsing element opening tags:
"if the element is one of the void elements, [after the attributes] there may be a single U+002F SOLIDUS (/) character. This character has no effect except to appease the markup gods. As this character is therefore just a symbol of faith, atheists should omit it."
e.g., HTML 5 ignores a slash in (e.g.) <br/>, whereas according to the HTML 4 spec it should be processed as SGML would process it: SGML would render it as if it had occurred just after the tag.
Consider, for example, a lone that doesn't terminate anything. Most browsers today treat that as a valid break, not an orphan tag to be ignored. XHTML was supposed to end that kind of nonsense.
A conforming HTML implementation should ignore such a tag, which is illegal in an HTML document. That they don't has nothing to do with the specification, and just shows that browser implementors do not support XHTML (in which such a tag is _legal_ and should not be rendered) as well as many claim they do.
The problem with XHTML has been that CSS layout was badly designed. "float" and "clear" just aren't a good set of layout primitives. Cell-based layout (yes, "tables") was a fundamentally more powerful concept. But it's not XHTML that's the problem. It's that the positioning mechanisms for "div" sections are terrible.
Layout is really a 2D constraint problem. Internally, you have constraints like "boxes can't overlap", which turns into constraints like "upper left corner of box B must be below lower left corner of box A", or "right edge of box A and left edge of box B must have same X coordinate". Browsers really ought to do layout that way. Table layout engines come close to doing that. At least with tables you never get text on top of other text. "div" doesn't have comparable power. "float" and "clear" represent a one-dimensional model of layout, and that's just not good enough.
It sounds like you, like me, feel that the real solution to all of these problems is a clean break from HTML and its legacy.
"For example, how does an old browser cope with the (hypothetical) new canvas element, which presents a canvas the user can draw an image on, which is submitted along with the rest of the form?"
As a rule, the standards developers are careful not to introduce new features that would cause breakage like that.
For example, there are new input types proposed. But all of them are specified using '<input type="blah">' tags, which (per the HTML 4 spec) degrade to being a text input if they aren't understood. In each case, the standard specifies the textual format that is used to transfer the data, and instructions could be given to a user to use this format. In the case of date entry fields, it probably won't be particularly helpful (few people want to work with ISO-formatted dates), but for the new '<input type="number">', complete backwards compatibility is assured.
Huh? Are you looking at the same site as me? I count 10 articles, of which:
1 is about the design of a core Java API 1 is about implementing a library in C 3 are completely language independent 1 is about a development environment called "Subtext" which has its own language 1 is about Haskell 1 is about the book discussed 2 are about object-oriented design, and use Java in example code (but the text of the article applies equally to any object-oriented language)
That doesn't seem to be particularly Java-focussed to me.
IE if it takes you 2 years to write beautiful correct code that is maintainable and works perfectly AND your project is two years late to market **you still suck**
If it takes 2 years to write the code and you're 2 years late to market, you really need to find another market.
If goto were not useful or necessary then languages would have dropped it years ago when CS profs started to dread it because they couldn't teach their students properly and got tired of spitting out idiot programmer after idiot programmer who tortured them with goto-ridden spaghetti code.
Which is presumably why languages like Pascal, Java, Python, Ruby, etc. all support goto.
Oh, wait, they don't. Almost no programming languages designed since the 1970s do. C# is the only exception I can think of, and that was probably only implemented because the framework had to support it (in order to support BASIC) and C# is intended to support everything the framework can do.
Need to use multiple database vendors with one code base? Fine, use stored procedures,
AKA write multiple implementations, one for each vendor.
standard SQL,
AKA cripple your program to the lowest common denominator. You'll spend hours working around the fact that different vendors do even basic things like giving a record a unique identifier in different ways.
or abstract the difference away.
Which is precisely what frameworks like Hibernate do.
There is a memory leak in your code. Or maybe it's a feature?
getBeer() may be using the flyweight pattern, and reusing previous beer instances (presumably after their.urinate() method has been called to, err..., release them). This is clearly why the otherwise pointless typecast to (Beer) is present: the method probably returns Lager, and the writer wanted it to be clear that it was more generic than that.
It can take a week to make significant changes to a web page in Struts or Spring MVC, where it use to take about a day to do it for the clients developed with the RAD tools of the late 90s
I have no experience of Struts, but if you have this problem with Spring MVC, you're using it wrong. Seriously. Spring MVC has helped me write some of the simplest, most maintainable web code I've ever worked with. Almost everything is automated: all I have to do in most situations for a common database view/query/update form is write a handful of lines of validation code, and usually a line or two of code to interact with a database access layer. The layout is produced in a GUI editor, and integration is a trivial matter of dropping tags in the right locations. Add a simple XML element to a config file and the page is integrated into the site and ready to work.
Yes externalizing code into config files can make a system more flexible (but you'll pay for it in readability and tracability/debugability).
If you're talking about Spring-style dependency injection, my experiences is that for almost any non-trivial code you'll more than gain anything you lose in readability or tracability in ease of writing unit tests.
Yes aspects of the agile methodology - continual integration and test driven coding - can help but they're not the only way and there's a cost associated.
Of course there's a cost. Writing code without tests is much faster than doing so with tests, but being confident that it's correct is the trick. Most of us aren't able to write correct code reliably, and the cost of delaying the fix to a bug until its picked out by testers (usually weeks or even months after the code is written) is normally substantially higher than writing unit tests at the same time as the code. And in my experience, writing tests first is faster than writing them immediately after: you get to think about your code design during the otherwise relatively easy stage of writing the test, so when you come to implement, you'll already have a fairly good idea of how to make the test pass. Test after often leaves me sitting, thinking about how to implement the feature, and then writing a mind-numbing test with just enough difficulty that I can't think about the next feature while I'm doing it.
it is impossible to predict the future and I've seen so many projects where the list of "to be supported in the future" lead to so much foundation code that's only purpose was to support features that never came to pass and they became bloated. Sure they had the room to support those features, but as the requirements grew further and further away from what the designers originally thought was going to happen, the application just ended up becoming a mess.
Extreme Programming has a maxim, "You Ain't Gonna Need It", which applies to this sort of situation. The idea is, you work on the program one feature at a time, and don't implement anything that you don't need for the feature you're currently working on. Because requirements change, there's a better than average chance that the framework code you're thinking about writing isn't necessary, or isn't quite right, or is complete overspecified. Implementing it later (when the requirements are better known) will be easier and less likely to cause waste.
One easy way to tell: remove the code, and see what breaks.
Only works if you have automated tests for every feature you've implemented and every bug you've fixed, but is there a good justification for not having such tests?
That sort of depends on whether or not Intellectual Property is subject to expropriation.
If so, and someone misuses your GPL'ed IP, then you might be able to order some their IP seized and handed over to you by way of compensation (and then you would be within your rights to release the source code, since it would now be yours to release). This, however, has not been tested in any court as far as I know.
I think it's highly unlikely that a court would order this. The compensation due would have to be determined in terms of monetary value, and before such an order was made an assessment of the value of the IP would have to be made. Such an assessment would be extremely difficult. The value would have to be similar to or less than the value of the compensation due (which is unlikely, unless your infringed IP is significantly more valuable than theirs).
In the mean time, the infringing party would have been given a compensation order, which they could settle at any time by paying in full. Doing so would prevent any order to hand over their IP.
Even if they don't, in order to simplify matters, a court would likely prefer either (a) an order to seize tangible assets or (b) if the tangible assets were not adequate to cover the compensation award a liquidation order -- in this case, the IP would have to be sold to the highest bidder in order to pay the monetary compensation owed.
Slashdot Mirror
I pose the question to Slashdot... What reason would a large organization have at this point to run Vista?
Integrated support for disk-image based installation, without the need for third party products.
Improved support for policies that allow more detailed management of what users can and can't do with their PCs.
Full drive encryption.
SoftGrid as part of the Desktop Optimization Pack, allows you to run applications in complete isolation from each other.
All of these are useful technologies for a large organization which are new to Vista (although, admittedly, some of them were previously available from third party suppliers for XP, having them integrated and MS-approved helps such an organization a lot).
In that case, please enlighten us. I certainly wasn't the only one, given the fact that my comment was moderated up...
VMWare licenses the Implimentation of Linux used in ESX from Red Hat, however nowhere is that mentioned in the Article.
Red Hat are not the copyright holders of (all of) Linux. They cannot license Linux under any terms other than the GPL.
By 'create' a tool, they do mean compilers like gcc & fpc, and of course the bash shell, right?
I posted an automated translation of the law in response to Fyodor's thread, above. But the relevant fact is that the "purpose" of the tool must be hacking. So, you'd be pretty safe with these. Fyodor's on a little muddier ground, though.
I find the idea that this is any worse than the UK law that passed strange:
Section (2) is much more general than the German law, requiring only that you believe it likely that the article supplied will be used in such a crime, while the German law requires intent that it be used in such a crime. Plus, the UK law allows 2 years imprisonment, the German law only one.
So, all in all, I'd say you're on much safer grounds visiting Germany than the UK over this one.
I've only ever heard it called meths, even though the spirit is singular.
No, no. The spirit is plural. Go find a bottle, it'll say "methylated spirits" on it. I believe the name derives from the traditional recipe of a mixture of ethanol (a spirit) with methanol (another spirit).
To adequately test business rules expressed in code is entirely possible - but the programmer has to either be a domain expert and psychic to boot or have a very good customer representative who not only actually understands and can communicate their requirements but is capable of verifying that the unit tests truly test those requirements.
l owed pass", which is much clearer: the reason for the _code_ is fully documented. The reason for the test is perhaps unknown, but that's perhaps a little easier for somebody to figure out later.
Business rules code with a 'why is this here?' comment pretty much guarantee that this is not the case. They indicate a feature that was a rush job for some reason, and the #1 rule of rush jobs is that the only requirement you get is "make this work. Right Now".
Ah, I see your point now. The comment is to explain that the _requirements_ are unclear, not that the code is. That makes some sense.
Still, such a comment wouldn't be in my code. The comment would say something more like "// this is necessary to make TestStupidObject.testThatInexplicableRule34aIsFol
For the original commenter who mentioned these comments, I don't think this was the case. I'm pretty sure he was talking about code that had been mysteriously added to fix something broken, where he understood what was broken at the time, but just lost track of what the fix was supposed to do later on.
My point is that if there is code to do something, there should be a unit test for it. If you understand the problem enough to write the code, surely you understand it enough to write a test that the code works correctly. I'll grant that you might not understand why the test is necessary, but that's an entirely different matter.
That works on the gross physical level, but suppose removing the 'why is this here?' code works to modify a high level object in such a way that doesn't break anything.
In that case, you don't have adequate unit tests. The key to writing unit tests properly is to make sure that for each code execution path in the application there is at least one test that will fail if you remove that path (or, conversely, using the approach of test driven development: don't implement a code path until there's a test that will show whether or not it worked). If you have followed this rule, then there will not be any code in your system that wouldn't break anything if it wasn't there.
Yes, the canvas tag is in there. It is, of course, already supported by Safari and Mozilla (and Opera, IIRC), and there's a free script that can be used to make IE support it as well, so there's little reason not to start using it already.
A serious question here: what features do you need that aren't covered by simply using 'display: table-cell' and 'display: table-row'?
I can think of a few that might be useful:
* Ability to define column/row orders independently of element order (i.e. something like 'table-cell-column-index:0' to force a cell to appear in the leftmost column, etc.)
* Ability to make an element span multiple rows or columns
* Regarding text flow in columns, etc., something like 'overflow-target: #nextelement' (need to think about how box sizing works in the presence of text overflowing into the next box)
It is going to take a long time before web developers can take advantages of these tags. We need the browsers to start using it which may take a while. Firefox may jump on first then maybe Safari and others IE will probably take 2-3 more years until it supports HTML 5.
Firefox and Safari have already implemented a lot of this stuff, and some of it is supported in IE already too (even if only by hacks). A good example is the 'canvas' tag. It was implemented in safari before the working group even started, and was implemented by firefox quite soon after it was added to the working draft of the standard. Scripts are available that implement it for IE as well. Other things are standardisations of what were previously IE-proprietary extensions (e.g. the 'contenteditable' system), so are already fully supported by IE, and will likely be available in firefox & safari soon.
-A height attribute that actually works?
Could you elucidate what's wrong with the current one? OK, so it isn't supported on enough elements, but...
Smarter Form controls
The proposal includes form controls for dates, times and numbers, plus pattern-matching on text fields.
Eliminate the need for putting a space in empty table cells.
Try adding 'empty-cells:show' to your CSS for the table declaration.
A big advantage of XHTML was that the conversion to a parse tree was unambiguous. Why give up that at this late date?
/>, whereas according to the HTML 4 spec it should be processed as SGML would process it: SGML would render it as if it had occurred just after the tag.
Nobody's giving up on that. One of the goals of HTML5 is to ease adoption of XHTML, for instance by removing details from the HTML specification that are incompatible with XHTML: e.g., in the description of parsing element opening tags:
"if the element is one of the void elements, [after the attributes] there may be a single U+002F SOLIDUS (/) character. This character has no effect except to appease the markup gods. As this character is therefore just a symbol of faith, atheists should omit it."
e.g., HTML 5 ignores a slash in (e.g.) <br
Consider, for example, a lone that doesn't terminate anything. Most browsers today treat that as a valid break, not an orphan tag to be ignored. XHTML was supposed to end that kind of nonsense.
A conforming HTML implementation should ignore such a tag, which is illegal in an HTML document. That they don't has nothing to do with the specification, and just shows that browser implementors do not support XHTML (in which such a tag is _legal_ and should not be rendered) as well as many claim they do.
The problem with XHTML has been that CSS layout was badly designed. "float" and "clear" just aren't a good set of layout primitives. Cell-based layout (yes, "tables") was a fundamentally more powerful concept. But it's not XHTML that's the problem. It's that the positioning mechanisms for "div" sections are terrible.
Layout is really a 2D constraint problem. Internally, you have constraints like "boxes can't overlap", which turns into constraints like "upper left corner of box B must be below lower left corner of box A", or "right edge of box A and left edge of box B must have same X coordinate". Browsers really ought to do layout that way. Table layout engines come close to doing that. At least with tables you never get text on top of other text. "div" doesn't have comparable power. "float" and "clear" represent a one-dimensional model of layout, and that's just not good enough.
It sounds like you, like me, feel that the real solution to all of these problems is a clean break from HTML and its legacy.
"For example, how does an old browser cope with the (hypothetical) new canvas element, which presents a canvas the user can draw an image on, which is submitted along with the rest of the form?"
As a rule, the standards developers are careful not to introduce new features that would cause breakage like that.
For example, there are new input types proposed. But all of them are specified using '<input type="blah">' tags, which (per the HTML 4 spec) degrade to being a text input if they aren't understood. In each case, the standard specifies the textual format that is used to transfer the data, and instructions could be given to a user to use this format. In the case of date entry fields, it probably won't be particularly helpful (few people want to work with ISO-formatted dates), but for the new '<input type="number">', complete backwards compatibility is assured.
This site's primary concern seems to be java
Huh? Are you looking at the same site as me? I count 10 articles, of which:
1 is about the design of a core Java API
1 is about implementing a library in C
3 are completely language independent
1 is about a development environment called "Subtext" which has its own language
1 is about Haskell
1 is about the book discussed
2 are about object-oriented design, and use Java in example code (but the text of the article applies equally to any object-oriented language)
That doesn't seem to be particularly Java-focussed to me.
IE if it takes you 2 years to write beautiful correct code that is maintainable and works perfectly AND your project is two years late to market **you still suck**
If it takes 2 years to write the code and you're 2 years late to market, you really need to find another market.
If goto were not useful or necessary then languages would have dropped it years ago when CS profs started to dread it because they couldn't teach their students properly and got tired of spitting out idiot programmer after idiot programmer who tortured them with goto-ridden spaghetti code.
Which is presumably why languages like Pascal, Java, Python, Ruby, etc. all support goto.
Oh, wait, they don't. Almost no programming languages designed since the 1970s do. C# is the only exception I can think of, and that was probably only implemented because the framework had to support it (in order to support BASIC) and C# is intended to support everything the framework can do.
Need to use multiple database vendors with one code base? Fine, use stored procedures,
AKA write multiple implementations, one for each vendor.
standard SQL,
AKA cripple your program to the lowest common denominator. You'll spend hours working around the fact that different vendors do even basic things like giving a record a unique identifier in different ways.
or abstract the difference away.
Which is precisely what frameworks like Hibernate do.
There is a memory leak in your code. Or maybe it's a feature?
.urinate() method has been called to, err..., release them). This is clearly why the otherwise pointless typecast to (Beer) is present: the method probably returns Lager, and the writer wanted it to be clear that it was more generic than that.
getBeer() may be using the flyweight pattern, and reusing previous beer instances (presumably after their
code sucks but I (and the 90% of programmers who make this claim) are in the remaining elite 10% that are coding Gods.
However you (unlike me) are not in the elite 10% of English-speakers who know how to use paranthetical phrases correctly.
It can take a week to make significant changes to a web page in Struts or Spring MVC, where it use to take about a day to do it for the clients developed with the RAD tools of the late 90s
I have no experience of Struts, but if you have this problem with Spring MVC, you're using it wrong. Seriously. Spring MVC has helped me write some of the simplest, most maintainable web code I've ever worked with. Almost everything is automated: all I have to do in most situations for a common database view/query/update form is write a handful of lines of validation code, and usually a line or two of code to interact with a database access layer. The layout is produced in a GUI editor, and integration is a trivial matter of dropping tags in the right locations. Add a simple XML element to a config file and the page is integrated into the site and ready to work.
Yes externalizing code into config files can make a system more flexible (but you'll pay for it in readability and tracability/debugability).
If you're talking about Spring-style dependency injection, my experiences is that for almost any non-trivial code you'll more than gain anything you lose in readability or tracability in ease of writing unit tests.
Yes aspects of the agile methodology - continual integration and test driven coding - can help but they're not the only way and there's a cost associated.
Of course there's a cost. Writing code without tests is much faster than doing so with tests, but being confident that it's correct is the trick. Most of us aren't able to write correct code reliably, and the cost of delaying the fix to a bug until its picked out by testers (usually weeks or even months after the code is written) is normally substantially higher than writing unit tests at the same time as the code. And in my experience, writing tests first is faster than writing them immediately after: you get to think about your code design during the otherwise relatively easy stage of writing the test, so when you come to implement, you'll already have a fairly good idea of how to make the test pass. Test after often leaves me sitting, thinking about how to implement the feature, and then writing a mind-numbing test with just enough difficulty that I can't think about the next feature while I'm doing it.
it is impossible to predict the future and I've seen so many projects where the list of "to be supported in the future" lead to so much foundation code that's only purpose was to support features that never came to pass and they became bloated. Sure they had the room to support those features, but as the requirements grew further and further away from what the designers originally thought was going to happen, the application just ended up becoming a mess.
Extreme Programming has a maxim, "You Ain't Gonna Need It", which applies to this sort of situation. The idea is, you work on the program one feature at a time, and don't implement anything that you don't need for the feature you're currently working on. Because requirements change, there's a better than average chance that the framework code you're thinking about writing isn't necessary, or isn't quite right, or is complete overspecified. Implementing it later (when the requirements are better known) will be easier and less likely to cause waste.
the comments turn into "// why is this here?"
One easy way to tell: remove the code, and see what breaks.
Only works if you have automated tests for every feature you've implemented and every bug you've fixed, but is there a good justification for not having such tests?
That sort of depends on whether or not Intellectual Property is subject to expropriation.
If so, and someone misuses your GPL'ed IP, then you might be able to order some their IP seized and handed over to you by way of compensation (and then you would be within your rights to release the source code, since it would now be yours to release). This, however, has not been tested in any court as far as I know.
I think it's highly unlikely that a court would order this. The compensation due would have to be determined in terms of monetary value, and before such an order was made an assessment of the value of the IP would have to be made. Such an assessment would be extremely difficult. The value would have to be similar to or less than the value of the compensation due (which is unlikely, unless your infringed IP is significantly more valuable than theirs).
In the mean time, the infringing party would have been given a compensation order, which they could settle at any time by paying in full. Doing so would prevent any order to hand over their IP.
Even if they don't, in order to simplify matters, a court would likely prefer either (a) an order to seize tangible assets or (b) if the tangible assets were not adequate to cover the compensation award a liquidation order -- in this case, the IP would have to be sold to the highest bidder in order to pay the monetary compensation owed.