|
Well, I don't create XSLTs on a daily basis, only once a month. Each time I have to go back to look at already created ones to see how to do it. It just doesn't seem natural to me, especially dealing with variables and parameters.
When I look at XSLTs in bigger projects that have been worked on for a while (by other people) - it makes XSL to look like a self-obfuscating language. People tend to put the whole application into one file (doesn't matter if it got 10.000 lines), do not properly group things, use copy & paste and the rest is done by the overhead of tags and symbols through XML.
It makes me think XSL is generally treated as throw-away code, like prototypes going into production.
|
|
|
|
|
Doc Lobster wrote: People tend to put the whole application into one file (doesn't matter if it got 10.000 lines), do not properly group things, use copy & paste and the rest is done by the overhead of tags and symbols through XML.
Ouch. Well, slap 'em around a bit. There's just no excuse for that.
|
|
|
|
|
Doc Lobster wrote: From time to time it is necessary for me to code xslt. Each time is a horror.
Eh, not so sure about that. Sure, the syntax is horrible, but the semantics make sense IMHO.
|
|
|
|
|
From time to time, it is necessary for me to review procedural XML translation code from people who don't know how to use XSLT. Each time is a horror... 
But who is the king of all of these folks?
|
|
|
|
|
Spot on - I'm having just such a horror going through current use in my project.
I think though that many developer's expect just to leap into XSLT as with most languages, without observing that it requires a paradigm shift from imperative to declarative logic.
Still hate the syntax though. XML is just way to verbose for some applications. I've heard justifications that a tree-like structure is well suited to such tasks, but as far I'm aware most parsers form a tree (Abstract Syntax Tree) representing the program structure, so that doesn't cut ice with me.
|
|
|
|
|
We have some third-party software that lets message objects accumulate in a huge LinkedList. How huge? They actually let it grow to fill up the heap and then catch the OutOfMemoryError. Even ignoring the question of whether this is a good design decision, their error-handling method leaves something to be desired.
if (throwable isinstance OutOfMemoryError)
{
System.gc();
throwable.printStackTrace();
}
If you don't instantly see what's wrong with that, here are some hints:
- The JVM will always attempt a garbage collection before throwing an
OutOfMemoryError. - Stack traces require string manipulation. Strings require memory...
|
|
|
|
|
ClementsDan wrote: If you don't instantly see what's wrong with that, here are some hints:
The JVM will always attempt a garbage collection before throwing an OutOfMemoryError.
Stack traces require string manipulation. Strings require memory...
But is this documented (in the Java API) along side the System.gc(); call? If not it should be, and would prevent such superfluous calls.
WPF - Imagineers Wanted
Follow your nose using DoubleAnimationUsingPath
|
|
|
|
|
ClementsDan wrote: The JVM will always attempt a garbage collection before throwing an OutOfMemoryError
Really? It does? Because the .NET garbage collector does not.
(Tess' MSDN blog.)
|
|
|
|
|
Not true. See Maoni's blog at http://blogs.msdn.com/maoni/archive/2006/06/06/when-memory-is-running-low.aspx[^].
"If you don't have enough physical storage we will fail when we need to commit memory. We attempt a GC at this point and if afterwards there's still not enough physical storage to commit we will throw an OOM.
"When you have a page file, physical storage includes both physical memory and the page file." -- from comment #3[^].
So the order goes:
- application tries to allocate memory
- existing heap VM segments are full
- try to create new segment
- cannot create a new segment (out of VA space or commit limit reached)
- performs a GC to compact heap
- if still not enough space available, fails with OutOfMemoryException.
DoEvents: Generating unexpected recursion since 1991
|
|
|
|
|
From Tess' blog:
"Virtual memory allocations are not necessarily (or very seldom) lined up nicely in memory. For example, dll’s have preferred loading addresses so gaps are left between them, and virtual allocations that have been de-allocated will also leave gaps. This means that even though you can address 2 GB of virtual memory you may not be able to use it all since when enough memory is used, the memory will look somewhat like a Swiss cheese and your plug might have a big enough hole to fit in.
This is what happens when you get an OutOfMemory exception."
It seems to me like what these two blogs are saying is conflicting, and I don't know which one to believe.
|
|
|
|
|
actually they're both right.
What Tess is saying is that even though the total free memory you have may be in theory enough to satisfy the request, it may be fragmented into many free blocks. None of these free blocks is large enough to satisfy the request.
Silence is the voice of complicity.
Strange women lying in ponds distributing swords is no basis for a system of government. -- monty python
Might I suggest that the universe was always the size of the cosmos. It is just that at one point the cosmos was the size of a marble. -- Colin Angus Mackay
|
|
|
|
|
That is indeed what Tess is saying, but she also says "that is what happens when you get an OutOfMemoryException". The other party claims the garbage collector will perform defragmentation (which is part of garbage collection, after all) before throwing OutOfMemoryException, and if that is true you wouldn't get OOM as long as the new allocation requires less than total free memory.
If so, the only time you should get the exception should be when the live objects are pinned. (Very large objects are said to be "pinned" because they are never moved in defragmentation due to the hard work it would be moving such big objects around.)
I guess if you want very much to conclude that they both are right you could assume Tess was talking about pinned objects, but that is a rather contrived way of getting there, and I frankly don't see the point. For me the important thing isn't who is right but what the fact is. And that is unfortunately still no more clear for me.
|
|
|
|
|
the point 2. seems to be very clever solved. 
Greetings from Germany
|
|
|
|
|
because in another post someone mentioned the lack of knowledge of arrays in childhood i got reminded of a funny spam-mail i once received.
they have such nice things like
var status1 = "";<br />
var status2 = "";<br />
var status3 = "";
or <a HreF="blah">.
enjoy here[^]
|
|
|
|
|
The rule of three: "The first time you notice something that might repeat, don't generalize it. The second time the situation occurs, develop in a similar fashion -- possibly even copy/paste -- but don't generalize yet. On the third time, look to generalize the approach."
(Now I've forgotten who said it; I had to find a post by leppie to get it.)
Need a status? Make one.
Need a second one? Go right ahead.
Need a third? Hey! They don't grow on trees!
It reminds me of a job I used to have... I was assigned the maintenance of the credit card processing part of the system. Each member's account had fields for credit card number, type, and expiration. So far so good.
Then we got a new client who wanted a backup credit card... OK, we added a second set of credit card number, type, and expiration plus a field to indicate which one was used last time to the table.
Then we got another new client who wanted to do EFT and before anyone told me about it, they added account and routing number (or whatever) to the table.
When I went to talk to the DBA and suggest we should have some sort of PaymentSource table that could have any number of sources associated with an account. His response was that, although it was a good idea, the inmates had taken over and there was nothing we could do at that point. 
|
|
|
|
|
PIEBALDconsult wrote: The rule of three: "The first time you notice something that might repeat, don't generalize it. The second time the situation occurs, develop in a similar fashion -- possibly even copy/paste -- but don't generalize yet. On the third time, look to generalize the approach."
Yes, very true.
"I guess it's what separates the professionals from the drag and drop, girly wirly, namby pamby, wishy washy, can't code for crap types." - Pete O'Hanlon
|
|
|
|
|
I found this code somewhere:
...
if (x == true)
return true ;
else
return false ;
Actual code was the body of a C# 3 lambda expression. Anyway, horrible.
|
|
|
|
|
Could be for debugging, for a breakpoint.
|
|
|
|
|
It's not THAT horrible. Yes, it's not exactly elegant, but sometimes this is done to make things clearer to other coders (especially less-experienced ones).
|
|
|
|
|
AEternal wrote: sometimes this is done to make things clearer to other coders (especially less-experienced ones).
But then how would they learn?
|
|
|
|
|
The senior programmer could place comments like this:
if (x == true)
return true;
else
return false;
codito ergo sum
|
|
|
|
|
Fair enough. 
|
|
|
|
|
Then it should be
return x ;
|
|
|
|
|
PIEBALDconsult wrote: I'll have you tied to an anthill and covered in honey!
Cute. This should get a Vote of '5'.
Vasudevan Deepak Kumar
Personal Homepage
Tech Gossips
A pessimist sees only the dark side of the clouds, and mopes; a philosopher sees both sides, and shrugs; an optimist doesn't see the clouds at all - he's walking on them. --Leonard Louis Levinson
|
|
|
|
|
or he could just save the time it takes to write that long, verbose comment and just write
return x;
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
