@Sutherlands said:
Except when it doesn't. Like using a simple C# property.
Yeah, using even the simplest of C# properties in Java has HUGE performance implications.
@Sutherlands said:
Except when it doesn't. Like using a simple C# property.
@KrakenLover said:
"Cannot reproduce."
Thank gods! Eventually, they'll die out and a more adaptable species will take over.
@TheCPUWizard said:
Where did I ever say anything about a single line? or even "block of logic"?
Nowhere. It was not your message I was replying to.
It might be a shock to you, but this is not a private conversation just between the two of us.
Whatever. I just remembered why my post count on here is so low. Pretend I wasn't here.
@TheCPUWizard said:
For the type of comments you posted (inline with the code) you are 100% correct. But that is NOT the purpose fo the XML code comments being discussed here.
Urr, the post I was replying to was "+1 clarity" on a single line of comment preceding each block of logic, documenting what it does. I have yet to see any meaningful XML comments in a single line, let alone preceding every single block of logic.
Oh well, live and learn.
Hmm...
Am I the only one around here that comments WHY the code does what it does, rather than WHAT it does?
The code clearly states what it does (or so help me, I shall bring the Peer Audit Hammer), so why repeat it in a comment?
print $foo; # Print the variable $foo to standard out.
NO REALLY?!
print $foo; # Debug output to check the state of $foo TODO: Remove at end of testing
@Cat said:
TRWTF is that you're making it so hard to change the business logic as to require your customers to bring in Perl experience to code their own. Honestly, it sounds like a deployment and maintenance nightmare, which will grow exponentially with the number of customers you have.
Well, we don't sell the software. We sell a service, and use this software internally to help provide that service.
This service currently has a single customer, but this customer is so incredibly huge that it warrants an entire in-house software suite to keep them happy.
If the needs change, so will the software.
For example, the "rules parser" could be hooked up to parse the rules into some elaborate database table layout, and we could write a nice front-end to manage that.
For now, however, it's far more cost-effective to just use vim.
Also, if the software was for customer eyes, I certainly would have sacrificed the near-instant performance of "pre-compiled configuration" for actual usability by the customer.
I mean, I wouldn't dream of making it this way in any of the open source stuff, for example.
@angelchen said:
Hello friends, <spam/>
I agree, that is TRWTF!
@trwww said:
and it only takes 5 minutes to spot that bug, not 5 days.
Especially considering this little peice I found just before where the finished SQL statement is returned:
# $this->debug->out("Full SQL Statement:\n $SQL");
...which means that spotting the problem is one # away.
Oh well, in all fairness git blame blames me for that #, so I have to take some of the blame for the whole thing
@vyznev said:
Obviously, you should change the format to replace those curly brackets around the "where" part with square brackets. That'll fix it.
(That actually is at least a half-serious suggestion. It will work, provided that you change the backend to accept an arrayref instead of a hashref.)
First, this is only a very small part of it. There is A LOT more to the business rules handling than the SQL part, such as priorities listing and weighing, etc etc, which is what I referred to as "classic line-noise-style Perl".
Secondly, he had absolute and full access to change this around as he saw fit, and rearrange anything in the backend/parser to do whatever, as long as the change was either compatible with my stuff or he changed my stuff to match.
I would have accepted a change like...
if (ref($rule) eq 'ARRAY'){ # Do his stuff } elsif (ref($rule) eq 'HASH'){ # Do my stuff }@trwww said:
Well, the API that is provided is pretty limiting.... SQL::Abstract has been around for 5 years now:DBIx::Class and SQLA quality is so impressive that I have to raise an eyebrow when something else is being used.
I'm quite familiar with SQL::Abstract, Ima::DBI, Class::DBI and most of the other even remotely relevant stuff.
They are all either massive performance killers or don't support the "removed for simplicity" stuff. :-)
They are also massively beside the point. He should still have spotted why it didn't work, and if not 9 days ago, then 8.