| Re: [OT] Was: Dynamic form generation [message #177884 is a reply to message #177883] |
Wed, 25 April 2012 11:46   |
The Natural Philosoph
Messages: 993
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
Erwin Moller wrote:
> On 4/24/2012 11:10 AM, Thomas 'PointedEars' Lahn wrote:
>
> <snip>
>
>> It is a yes-or-no question, therefore it cannot be incorrect.
>>
>
> Yes, even yes-or-no questions can be incorrect, in the sense that both
> "yes" and "no" are incorrect answers.
>
> Here is an example:
> "This sentence is not true. Is the former sentence correct? Yes or no?"
>
"Have you stopped beating your wife?: Yes or no?"
There are some good examples of unanswerable questions somewhere on a
philosophy forum..
>
> Regards,
> Erwin Moller
>
>
--
To people who know nothing, anything is possible.
To people who know too much, it is a sad fact
that they know how little is really possible -
and how hard it is to achieve it.
|
|
|
|
| Re: Dynamic form generation [message #177887 is a reply to message #177876] |
Wed, 25 April 2012 12:29 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 4/25/2012 5:04 AM, Tony Marston wrote:
> "Jerry Stuckle"<jstucklex(at)attglobal(dot)net> wrote in message
> news:jn71ur$o4l$1(at)dont-email(dot)me...
>> On 4/24/2012 1:21 PM, Tony Marston wrote:
>>> "Jerry Stuckle"<jstucklex(at)attglobal(dot)net> wrote in message
>>> news:jn13eu$4ll$1(at)dont-email(dot)me...
>>> <snip>
>>>> >> And you completely miss the question. How do you change a single
>>>> >> property in the object without building the array?
>>>> >
>>>> > BECAUSE THE ARRAY IS ALREADY INSIDE THE OBJECT, YOU IDIOT!!! I don't
>>>> > need code inside the table object to build the array as it is supplied
>>>> > as an array, either from the $_GET or $_POST array, or an array of rows
>>>> > and columns from the database.
>>>>
>>>> So, IOW, you can't change a single property from the program. You
>>>> can't,
>>>> for instance, set just the ship date in an order. You can only set the
>>>> entire object. How stupid.
>>>
>>> If I have a transaction where the only value that can be changed in the
>>> ship
>>> date for an order, then the $POST array will contain "ship_date =
>>> whatever".
>>>
>>> My update controller has the line $dbobject->updateRecord($_POST) where
>>> $dbobject is an instance of the order class.
>>>
>>> The order class, as with every other table class in my system, will
>>> perform
>>> an update operation using the contents of its input array however many
>>> fields it contains. It does not matter whether it contains 1 field or 100
>>> fields, it's all the same.
>>>
>>> Why can't you understand such a simple concept?
>>
>> And an intelligent system will just have a button that says "order
>> shipped" with the program filling in the date. No input field required!
>
> You question was not "how can you set a value which was not included in the
> $_POST array?"
>
> If I have a transaction whose function "set the ship_date to today for all
> selected orders" then all it has to work on is an array of order numbers. I
> would iterate through this array using code similar to the following:
>
> foreach ($order_array as $order) {
> $order['ship_date'] = $today;
> $orderObject->updateRecord($order);
> }
>
> See? Neat and tidy,clean and simple.
>
Yup, and I see that you could just as easily say
$today = 'this is crap';
foreach ($order_array as $order) {
$order['ship_date'] = $today;
$orderObject->updateRecord($order);
}
And it will try to do it just fine - until it comes time to perform the
actual update.
Or even
$today = '2099-12-31';
<same as above>
And it will very happily do it.
>> In a real OO system you don't need to use the $_POST array - the program
>> can update individual items and still ensure the data are valid.
>>
>> Why can't you understand such a simple concept?
>
> That is not the question you asked, therefore it is not the question I
> answered.
>
Sure it was. You just can't understand such a simple question. Or you
evaded it on purpose. Which was it?
>>>> >> From the number of times you have ducked the question, my only
>>>> >> assumption can be the program can't change a single property in the
>>>> >> object.
>>>> >
>>>> > Changing a property inside an object is as simple as changing a value
>>>> > in
>>>> > an array.
>>>>
>>>> Oh, so all of your variables are public? How stupid is that? It
>>>> violates
>>>> the first rule of OO programing - encapsulation.
>>>
>>> Encapsulation does not mean data hiding.
>>>
>>
>> I never claimed it does. I said it means CONTROLLED ACCESS.
>
> Encapsulation does not mean data hiding. Encapsulation does not mean
> controlled access to data. The defintion of encapsulation does not require
> that either methods or properties have their access limited in any way
> whatsover.
>
You're the only one who claims it is data hiding. It DOES mean
controlling access to the data.
Otherwise why even have encapsulation? What is its purpose?
>>>> So you're saying I can say
>>>>
>>>> $object->ship_date = 9999-12-31. Or even
>>>>
>>>> $object->ship_date = "This is completely stupid but OK according to
>>>> Tony".
>>>
>>> I've already told you that I don't have a separate class property for
>>> each
>>> column in the table. All the table data is held in a single array, so
>>> instead of
>>>
>>> $object->ship_date = '9999-12-31'
>>> you would have to use
>>> $object->fieldarray['ship_date'] = '9999-12-31';
>>>
>>> Such duff data would never make it to the database anyway as it would
>>> fail
>>> the validation.
>>
>> According to your comments, such a construct will never be validated. So
>> how can it fail validation?
>
> I have already explained that I validate the entire contents of the input
> array with a single call to my validation object before any data gets
> written to the database. Any validation errors cause the table object to
> immediately return to the controller so that the screen can be redisplayed
> with the error message so that the user can correct his error and re-submit.
>
According to your own comments, such a construct will never be
validated, so it will fail validation.
And validating something hundreds of thousands of lines after it has
been set to an incorrect value is almost worthless. It should be done
at the time of the error.
But I also understand that's not a problem for you because you've never
written a complicated program. Just simple database access stuff.
>>>> Proper OO programming doesn't allow such crap programming.
>>>
>>> OO does not prevent programmers from writing crap code. It just allows
>>> then
>>> to generate a different class of crap.
>>
>> I never claimed it did. But proper design and implementation means good
>> code.
>
> How is my design improper? I ensure that all user input is validated before
> it gets written to the database, and I can do so without the programmer
> having to write a single line code.
>
It doesn't implement encapsulation. It doesn't properly use methods. A
change in the database (i.e. changing a column name) requires changing
the program. It exposes the names of the table columns you're using.
I could continue, but I know you'll discount everything I say. Crap
programmers do that when informed why their code is crap. Good
programmers try to learn.
> <snip>
>>>> With proper OO principles, the object requiring the rule implements the
>>>> rule.
>>>
>>> But the rule has to be coded within the relevant class.
>>
>> That is correct. That's why the class is independent of the rest of the
>> program. It implements it's own rules and data, which can be changed as
>> long as the public methods don't change.
>
> Exactly, and that is what my framework achieves. The business rules for each
> entity are coded within the entity's class.
>
And changes to the database require changes to your code. What happens,
for instance, if you change the name of the column 'ship_date'?
Or if you change it to three columns - ship_month, ship_date, ship_year?
> <snip>
>>> I don't have separate getter and setter functions for each entry within
>>> the
>>> array because the data goes in and out as an array.
>>
>> And in order for the program to set an individual item it must build an
>> array - having to know the internal workings of the class.
>
> So how is $this->foo = 'bar' or $this->setFoo('bar') any different from
> $this->fieldarray['foo'] = 'bar'? You still have to have a line of code
> which says "set the value of 'foo' to 'bar'". They are just different
> instructions which achieve the same result. You still have to know that the
> table object has a column called 'foo', so how does this expose the internal
> workings of the class?
>
Because $this->setFoo('bar') validates the data right then. And the
table column may or may not be called 'foo', and the internal object may
or may not be called 'foo'. In fact, the table object may be three
different columns. for instance.
>>>> Having instantiate the object just to ensure a value is an integer when
>>>> a
>>>> simple call to intval() does the same thing is bloat.
>>>>
>>>> But then you don't validate things set by the program, because you don't
>>>> understand encapsulation.
>>>
>>> I understand encapsulation very well. The validation rules for the person
>>> entity are defined within the person class. When I call the validation
>>> object I give it two variables - the array of field values and the array
>>> of
>>> field rules. The validation object will then verify that each field's
>>> value
>>> conforms to its rules.
>>
>> Obviously you don't understand encapsulation at all.
>
> Encapsulation has nothing to do with data validation.
>
Encapsulation has EVERYTHING do do with ensuring valid data.
> <snip>
>>>> So tell me - how do you prevent
>>>>
>>>> $object->ship_date = "This is stupid!";
>>>
>>> Because the validation rule for the field called "ship_date" is that it
>>> be a
>>> date, so the value "This is stupid!" will be rejected.
>>
>> It can't be, because you have repeatedly stated the validation is done on
>> an input array. There is nothing to stop me from putting that in the
>> variable in the class because you don't have setter functions.
>
> If you try the line $object->ship_date = "This is stupid!"; then you are not
> updating the data array, and it is the data array which is used to update
> the database. This means that your line of code will achieve nothing as the
> property 'ship_date' will never be referenced anywhere.
>
OK, so you say $object->['ship_date'] = "This is stupid!";
But I know you're too stoopid to understand the concept, even if the
actual statement isn't updating the array.
Or how about:
$object = 'Really crap!';
> <snip>
>>> The fact that the function accepts an array as its input is irrelevant as
>>> you are still spliting the array into its component parts.
>>
>> So? It has to be split into component parts anyway before inserting into
>> the database. My way does it on input.
>
> In my framework the data array is never split into its component parts until
> it appears in the data access object where the SQL statement is constructed
> and executed.
>
So? It has to be split.
>> The advantage is that ALL write access to the object is controlled and
>> validated because the programmer can't access private variables directly.
>> Yours doesn't do that.
>
> Irrelevant. All input is validated before it gets written to the database.
> How I validate and when I validate is irrelevant.
>
Completely relevant, if you're writing a complex program. But you've
never done anything complex, so you wouldn't understand.
In a complicated program the invalid value may be set thousands of lines
before you actually update the database. The error should be detected
when the value is set, not much later.
>>>> The lack of getters and setters means your variables must be public,
>>>> which
>>>> violates the first principle of OO programming - encapsulation.
>>>
>>> Encapsulation does not mean data hiding.
>>
>> You're the only one who keeps bringing up data hiding.
>
> Incorrect. It is *YOU* who keeps saying that I must use getters and setters
> because I should not access an object's properties directly (i.e. the
> properties should be hidden)
>
Which has nothing to do with data hiding. You're the only one who
brings up data hiding.
>>>> >> That's right. That's an implicit part of OO (encapsulation).
>>>> >
>>>> > Using getters and setters has nothing to do with encapsulation.
>>>>
>>>> Only in the alternate universe of Tony Marston. You really should try
>>>> reading a book on OO by a recognized expert in the field. Booch would
>>>> be
>>>> a good start.
>>>
>>> There are many others who also think that encapsulation does NOT mean
>>> data
>>> hiding. take a look at the following:
>>>
>>> http://www.javaworld.com/javaworld/jw-05-2001/jw-0518-encapsulation.html
>>> http://www.itmweb.com/essay550.htm
>>> http://homepage.mac.com/keithray/blog/2006/02/22/ - the 2nd paragraph
>>> titled
>>> "Encapsulation Wasn't Meant To Mean Data Hiding" written by martin
>>> Fowler.
>>
>> You're the only one who keeps bringing up data hiding.
>
> Incorrect. See above.
>
You're the only one who brings up data hiding.
> <snip>
>>> It is not a claim it is a fact that it is possible to have the same
>>> interface in more than one object WITHOUT inheritance.
>>
>> Sure you can. But that is not polymorphism.
>
> If you have "same interface, different implementation" then you have
> polymorphism. The "same interface" can either be inherited or hard-coded.
>
> <snip>
>> Polymorphism does not relate to siblings. Only to parent/child
>> relationships.
>
> You are missing the point. All these siblings have the SAME PARENT therefore
> they inherit all the methods of the parent.
>
No, your understanding of polymorphism is just as bad as your
understanding of encapsulation. There is no polymorphism between
siblings. Only when you have a parent-child relationship.
> <snip>
>>>> No, your way doesn't work.
>>>
>>> Yes it does, and has done for years. You can visit the demo radicore
>>> application at http://www.radicore.org/demo.php and try it out for
>>> yourself.
>>>
>>> Where is the link to YOUR framework?
>>
>> Absolutely of no consequence. The fact I do not want to waste my time
>> answering anal questions from the likes of you is my choice.
>
> So you don't want to answer anal questions, but you spend your time asking
> them.
>
I'm not asking anal questions. I'm trying to teach a pig to fly. But I
know that's a waste of time. And calling you a stoopid programmer is an
insult to stoopid programmers everywhere.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: Dynamic form generation [message #177888 is a reply to message #177872] |
Wed, 25 April 2012 12:34 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 4/25/2012 3:52 AM, Tony Marston wrote:
> "Jerry Stuckle"<jstucklex(at)attglobal(dot)net> wrote in message
> news:jn3mi4$29f$1(at)dont-email(dot)me...
> <snip>
>> Again, true. Good programmers can agree on what's good code and what's
>> crap code. Just because someone does things a different way doesn't make
>> it "bad".
>>
>> And I've found a direct correlation between the quality of a programmer
>> and his/her willingness to accept criticism.
>
> I can accept criticism in the form of "you do it that way, but wouldn't this
> way be better?", but all you sem to do is state time and timer again "your
> way is different from mine, therefore it must be crap".
>
No, you can't. I've tried to tell you which ways are better, as
indicated by world-recognized experts. But you're too stoopid to
understand. You won't even pick up a book by one of those experts.
>> Good programmers can take suggestions on their own code objectively. Poor
>> programmers will defend their crap until the day they die (and longer if
>> they could).
>
> I would always welcome suggestions to improve my code, but by "improve" I do
> *NOT* mean "make it the same as mine". If I did everything the same as you
> then I would be no better than you, and I'm afraid that your best is not
> good enough.
>
No, you don't. All you do is defend your crap, which goes against many
recognized good practices.
> The fact that my methods of achieving a result are different from yours does
> not make my methods "wrong", only "different". They work, therefore they are
> not wrong.
>
The fact you don't even understand basic concepts like encapsulation
makes your code crap.
> You have not provided any code samples that demonstrate that your methods
> are superior, so why should I or anyone else believe that your methods are
> superior? Just be cause you say so?
>
I don't need to. I've told you show it should be done (i.e. private
variables, setters/getters, etc.). But you've discounted all of that.
Read some books by world-recognized experts. But I know that's beyond
your comprehension. The only thing you'll read is someone who agrees
with you on the internet.
But I'm tired of trying to teach a pig to sing. You can have the last
word. Idiots need that.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: Dynamic form generation [message #177907 is a reply to message #177887] |
Thu, 26 April 2012 11:45 |
Tony Marston
Messages: 57
Registered: November 2010
Karma: 0
|
Member |
|
|
"Jerry Stuckle" <jstucklex(at)attglobal(dot)net> wrote in message
news:jn8qng$h7u$1(at)dont-email(dot)me...
<snip>
>> If I have a transaction whose function "set the ship_date to today for
>> all
>> selected orders" then all it has to work on is an array of order numbers.
>> I
>> would iterate through this array using code similar to the following:
>>
>> foreach ($order_array as $order) {
>> $order['ship_date'] = $today;
>> $orderObject->updateRecord($order);
>> }
>>
>> See? Neat and tidy,clean and simple.
>
> Yup, and I see that you could just as easily say
>
> $today = 'this is crap';
> foreach ($order_array as $order) {
> $order['ship_date'] = $today;
> $orderObject->updateRecord($order);
> }
>
> And it will try to do it just fine - until it comes time to perform the
> actual update.
>
> Or even
> $today = '2099-12-31';
> <same as above>
>
> And it will very happily do it.
Incorrect. Data that is input into an object is validated before it gets
written to the database. It it fails the validation it doesn't get to the
database.
>>> In a real OO system you don't need to use the $_POST array - the program
>>> can update individual items and still ensure the data are valid.
Data normally comes from the user as a result of hitting SUBMIT on a form,
which means that it is presented to the script as the $_POST array.
>>> Why can't you understand such a simple concept?
>>
>> That is not the question you asked, therefore it is not the question I
>> answered.
>
> Sure it was. You just can't understand such a simple question. Or you
> evaded it on purpose. Which was it?
You did NOT ask the question "How can you update a field which was not
passed in via the $_POST or $_GET array?" Your question actually was "How do
you change a single property in the object without building the array?"
Considering that every page request automatically comes with either the
$_GET or $_POST array I do not have to "build" the array as it is already
there. If I want to I can add as many other values to the array as I want.
<snip>
>>>> > Oh, so all of your variables are public? How stupid is that? It
>>>> > violates the first rule of OO programing - encapsulation.
>>>>
>>>> Encapsulation does not mean data hiding.
>>>
>>> I never claimed it does. I said it means CONTROLLED ACCESS.
>>
>> Encapsulation does not mean data hiding. Encapsulation does not mean
>> controlled access to data. The definition of encapsulation does not
>> require
>> that either methods or properties have their access limited in any way
>> whatsover.
>
> You're the only one who claims it is data hiding. It DOES mean
> controlling access to the data.
Controlling access means changing a property's visibility from "public"
(visible) to "private" (hidden). A public property can be accessed directly,
whereas a private propery can only be accessed via a getter or a setter.
So, "controlling access" *DOES* mean hiding the data, and encapsulation
*DOES NOT* mean data hiding.
The original definition of encapsulation mentioned "implementation hiding"
which is *NOT* the same thing as "information hiding". I have posted several
links to articles written by other people, including Martin Fowler (the
autor of Patterns of Enterprise Architecture), who say the same thing.
>>>> > So you're saying I can say
>>>> >
>>>> > $object->ship_date = 9999-12-31. Or even
>>>> >
>>>> > $object->ship_date = "This is completely stupid but OK according to
>>>> > Tony".
>>>>
>>>> I've already told you that I don't have a separate class property for
>>>> each
>>>> column in the table. All the table data is held in a single array, so
>>>> instead of
>>>>
>>>> $object->ship_date = '9999-12-31'
>>>> you would have to use
>>>> $object->fieldarray['ship_date'] = '9999-12-31';
>>>>
>>>> Such duff data would never make it to the database anyway as it would
>>>> fail the validation.
>>>
>>> According to your comments, such a construct will never be validated. So
>>> how can it fail validation?
>>
>> I have already explained that I validate the entire contents of the input
>> array with a single call to my validation object before any data gets
>> written to the database. Any validation errors cause the table object to
>> immediately return to the controller so that the screen can be
>> redisplayed
>> with the error message so that the user can correct his error and
>> re-submit.
>
> According to your own comments, such a construct will never be validated,
> so it will never fail validation.
I have already told you that all input *IS* validated before it gets sent to
the database.
> And validating something hundreds of thousands of lines after it has been
> set to an incorrect value is almost worthless. It should be done at the
> time of the error.
When I chose to perform the data validation is entirely up to me. I do not
input data one field at a time using a setter, therefore I don't validate
the field's contents within the setter. All the data is injected as a single
array, and I validate the entire contents array in a single call to my
validation object before it is passed to my data access object which updates
the database.
The fact that I do not perform this validation in exactly the same way as
you does not mean that my way is wrong. It is simply different.
> But I also understand that's not a problem for you because you've never
> written a complicated program. Just simple database access stuff.
>
>>>> > Proper OO programming doesn't allow such crap programming.
>>>>
>>>> OO does not prevent programmers from writing crap code. It just allows
>>>> them to generate a different class of crap.
>>>
>>> I never claimed it did. But proper design and implementation means good
>>> code.
>>
>> How is my design improper? I ensure that all user input is validated
>> before
>> it gets written to the database, and I can do so without the programmer
>> having to write a single line code.
>
> It doesn't implement encapsulation.
The definition of encapsulation is "The act of placing data and the
operations that perform on that data in the same class". That is exactly
what I do. The fact that *YOUR* definition has been expanded to include
other so-called "rules" is irrelevant. I am sticking to the original
definition.
> It doesn't properly use methods.
There is no rule as to how methods *SHOULD* be used, just that a class
contains the methods which can opeate on its data.
> A change in the database (i.e. changing a column name) requires changing
> the program.
If you change a column name in your database then some code *HAS* to change
somewhere. This applies to everybody's code, not just mine. And even to
yours (if you ever write any that is).
> It exposes the names of the table columns you're using.
So what? Using the same column names in your screen that appear in the
database is not wrong. In my long career if anyone suggested using different
names they would be fired for stupidity.
> I could continue, but I know you'll discount everything I say.
At last you've said some with which I can agree.
> Crap programmers do that when informed why their code is crap.
The fact that *YOU* think my code is crap does not concern me in the least
as I place absolutely no value on your opinions.
> Good programmers try to learn.
You can't learn anything from a bad teacher.
<snip>
>>>> > With proper OO principles, the object requiring the rule implements
>>>> > the
>>>> > rule.
>>>>
>>>> But the rule has to be coded within the relevant class.
>>>
>>> That is correct. That's why the class is independent of the rest of the
>>> program. It implements it's own rules and data, which can be changed as
>>> long as the public methods don't change.
>>
>> Exactly, and that is what my framework achieves. The business rules for
>> each
>> entity are coded within the entity's class.
>
> And changes to the database require changes to your code. What happens,
> for instance, if you change the name of the column 'ship_date'?
>
> Or if you change it to three columns - ship_month, ship_date, ship_year?
Such changes to the database structure would require changes in anybody's
code, even yours. That is an inescapable fact.
<snip>
>> So how is $this->foo = 'bar' or $this->setFoo('bar') any different from
>> $this->fieldarray['foo'] = 'bar'? You still have to have a line of code
>> which says "set the value of 'foo' to 'bar'". They are just different
>> instructions which achieve the same result. You still have to know that
>> the
>> table object has a column called 'foo', so how does this expose the
>> internal
>> workings of the class?
>
> Because $this->setFoo('bar') validates the data right then.
But I don't have to use a setter to validate data, I can validate it
whenever and however I want. I don't inject variables one at a time using
setters, so I don't validate it in the setter. I inject all the data as a
single array, and I validate the entire contents of the array with a single
call to my validation object before it is sent to the database.
> And the table column may or may not be called 'foo', and the internal
> object may or may not be called 'foo'. In fact, the table object may be
> three different columns. for instance.
You are now adding unecessary complexity, so I shall not waste my time
explaining how I would deal with such a scenario.
<snip>
>>> Obviously you don't understand encapsulation at all.
>>
>> Encapsulation has nothing to do with data validation.
>
> Encapsulation has EVERYTHING do do with ensuring valid data.
There is nothing in the definition of encapsulation which dictates when and
how the data is validated. How I choose to do it and when I choose to do it
is *MY* choice, not yours.
>> <snip>
>>>> > So tell me - how do you prevent
>>>> >
>>>> > $object->ship_date = "This is stupid!";
>>>>
>>>> Because the validation rule for the field called "ship_date" is that it
>>>> be a date, so the value "This is stupid!" will be rejected.
>>>
>>> It can't be, because you have repeatedly stated the validation is done
>>> on
>>> an input array. There is nothing to stop me from putting that in the
>>> variable in the class because you don't have setter functions.
If you put that variable directly into the class instead of its data array
then it will be ignored simply because all the table objects use a single
array for all the table data.
>> If you try the line $object->ship_date = "This is stupid!"; then you are
>> not
>> updating the data array, and it is the data array which is used to update
>> the database. This means that your line of code will achieve nothing as
>> the
>> property 'ship_date' will never be referenced anywhere.
>
> OK, so you say $object->['ship_date'] = "This is stupid!";
>
> But I know you're too stoopid to understand the concept, even if the
> actual statement isn't updating the array.
It should be obvious to anyone that if you inject a piece of data into an
object using the wrong name then the object will ignore that data. The
object is coded to look for data with particular names, so if you use the
wrong name the fault is yours and not the object's.
> Or how about:
>
> $object = 'Really crap!';
Now you are being silly!
>> <snip>
>>>> The fact that the function accepts an array as its input is irrelevant
>>>> as
>>>> you are still spliting the array into its component parts.
>>>
>>> So? It has to be split into component parts anyway before inserting
>>> into
>>> the database. My way does it on input.
>>
>> In my framework the data array is never split into its component parts
>> until
>> it appears in the data access object where the SQL statement is
>> constructed
>> and executed.
>
> So? It has to be split.
Not in the table object, only in the data access object. And it is *NOT*
split so that it can be injected into the object one piece at a time using
setters.
>>> The advantage is that ALL write access to the object is controlled and
>>> validated because the programmer can't access private variables
>>> directly.
>>> Yours doesn't do that.
>>
>> Irrelevant. All input is validated before it gets written to the
>> database.
>> How I validate and when I validate is irrelevant.
>
> Completely relevant, if you're writing a complex program. But you've
> never done anything complex, so you wouldn't understand.
How and when input data is validated is irrelevant. It is only important
that it *IS* validated.
> In a complicated program the invalid value may be set thousands of lines
> before you actually update the database. The error should be detected
> when the value is set, not much later.
I repeat, how and when input data is validated is irrelevant. It is only
important that it *IS* validated.
>>>> > The lack of getters and setters means your variables must be public,
>>>> > which
>>>> > violates the first principle of OO programming - encapsulation.
>>>>
>>>> Encapsulation does not mean data hiding.
>>>
>>> You're the only one who keeps bringing up data hiding.
>>
>> Incorrect. It is *YOU* who keeps saying that I must use getters and
>> setters
>> because I should not access an object's properties directly (i.e. the
>> properties should be hidden)
>
> Which has nothing to do with data hiding. You're the only one who brings
> up data hiding.
Controlling access means changing a property's visibility from "public"
(visible) to "private" (hidden). A public property can be accessed directly,
whereas a private propery can only be accessed via a getter or a setter.
So, "controlling access" *DOES* mean hiding the data, and encapsulation
*DOES NOT* mean data hiding.
The original definition of encapsulation mentioned "implementation hiding"
which is *NOT* the same thing as "information hiding".
There are many others who also think that encapsulation does NOT mean data
hiding. Take a look at the following:
http://www.javaworld.com/javaworld/jw-05-2001/jw-0518-encapsulation.html
http://www.itmweb.com/essay550.htm
http://homepage.mac.com/keithray/blog/2006/02/22/ - the 2nd paragraph titled
"Encapsulation Wasn't Meant To Mean Data Hiding" written by Martin Fowler.
>>> You're the only one who keeps bringing up data hiding.
>>
>> Incorrect. See above.
>>
>
> You're the only one who brings up data hiding.
>
>> <snip>
>>>> It is not a claim it is a fact that it is possible to have the same
>>>> interface in more than one object WITHOUT inheritance.
>>>
>>> Sure you can. But that is not polymorphism.
>>
>> If you have "same interface, different implementation" then you have
>> polymorphism. The "same interface" can either be inherited or hard-coded.
>>
>>> Polymorphism does not relate to siblings. Only to parent/child
>>> relationships.
>>
>> You are missing the point. All these siblings have the SAME PARENT
>> therefore
>> they inherit all the methods of the parent.
>
> No, your understanding of polymorphism is just as bad as your
> understanding of encapsulation. There is no polymorphism between
> siblings. Only when you have a parent-child relationship.
Polymorphism requires that different objects have the same interface (method
names). All siblings (i.e. subclasses which all inherit from the same
superclass) inherit all the method names from the superclass, so the same
method names are available in all the siblings. So, because the same method
names can be used on *ANY* of the siblings you automatically have
polymorphism.
--
Tony Marston
http://www.tonymarston.net
http://www.radicore.org
|
|
|
|
| Re: [OT] Was: Dynamic form generation [message #177908 is a reply to message #177883] |
Thu, 26 April 2012 11:51 |
Tony Marston
Messages: 57
Registered: November 2010
Karma: 0
|
Member |
|
|
"Erwin Moller" <erwinmollerusenet(at)xs4all(dot)nl> wrote in message
news:4f97de59$0$6976$e4fe514c(at)news2(dot)news(dot)xs4all(dot)nl...
> On 4/24/2012 11:10 AM, Thomas 'PointedEars' Lahn wrote:
>> It is a yes-or-no question, therefore it cannot be incorrect.
>
> Yes, even yes-or-no questions can be incorrect, in the sense that both
> "yes" and "no" are incorrect answers.
>
> Here is an example:
> "This sentence is not true. Is the former sentence correct? Yes or no?"
Your example is irrelevant. The original statement came in 2 parts:
(1) "This means that you perform no type conversion or checking, or range
checking in the application."
followed by the question
(2) "yes?".
The question (2) I read as "is the statement (1) correct or incorrect?" to
which I answered "incorrect".
--
Tony Marston
http://www.tonymarston.net
http://www.radicore.org
|
|
|
|
| Re: Dynamic form generation [message #177913 is a reply to message #177845] |
Thu, 26 April 2012 16:29 |
Tony Marston
Messages: 57
Registered: November 2010
Karma: 0
|
Member |
|
|
"Jerry Stuckle" <jstucklex(at)attglobal(dot)net> wrote in message
news:jn3vn9$vme$1(at)dont-email(dot)me...
<snip>
>> You call my code bloated because I have included the option to change the
>> password validation rules by changing values on a screen whereas you have
>> to
>> change the code. My method may have taken slightly longer to code, but it
>> also means that changes are easier to implement.
>
> I call your code bloated because it contains extra code for an unnecessary
> function no one else does because it's a "feature" no one needs and no one
> asks for.
Then how do you account for the fact that the only reason I added that
featue into my framework is because someone actually asked for it?
> A simple one line of code will do what your complicated database access,
> parsing and checking will do. That one line of code is not only more
> efficient but can handle many more possibilities.
Yes, but my method will allow the customer to change the rules on a screen
instead of asking me to change some code.
>> You call my code overly complicated because it has a pre-written
>> validation
>> class whereas to have to write code to validate each piece of user input.
>
> Yes, your code is unnecessarily complicated when it has to have an entire
> class to do what a single line of code will do more clearly and more
> efficiently.
You are missing the point AGAIN! Using your method you actually have to
write a line of code for each field that needs to be validated. With my
method you don't have to write any code at all as the framework
automatically calls the validation object to validate eveything in the input
array at a single stroke.
>> You say that my code does not follow "generally recognized rules" for no
>> other reason that the rules which it *DOES* follow are not the same as
>> yours. There is no single set of rules that is universally folowed by all
>> programmers, so I follow the rules which I consider to be the most
>> appropriate.
>
> Once again you need to actually UNDERSTAND OO programming. These are not
> "my rules" - they are long established "rules" accepted by
> world-recognized experts on the subject.
Different groups of developers have different sets of arbitrary "rules" or
"standards" which exist on top of basic programming principles. There is no
single set of rules which is universally adopted by *ALL* programmers. The
"rules" that I follow are not necessarily the same rules that you follow,
but so what? Who says that *YOUR* rules are he only rules that are allowed
to exist?
As for my understanding of the principles of OO programming, I simply stick
to the basic principles of encapsulation, inheritance and polymorphism as
documented in http://www.tonymarston.net/php-mysql/what-is-oop.html Anything
other than the basic principles is an optional extra, is totally
superfluous, and can safely be ignored.
<snip>
>>> I'm not saying every member of this group is stupid or incompetent.
>>> There
>>> are a number of people here who are quite intelligent and competent,
>>> whose
>>> opinions I regard highly.
>>
>> Only those who dare not disagree with anything you say. I am the
>> founder-member of the "I disagree with everything that Jerry Stuckle
>> says"
>> society, so I don't think I'm in that group. Ask me if I care!
>>
>
> Nope, there are people I disagree with here but still respect. I, too,
> have learned from those people.
I can't learn from you for the simple reason that you can't teach me
anything of value.
<snip>
>>> Yes, you've already said you don't understand one of the basic
>>> principles
>>> of OO programming - encapsulation.
>>
>> Encapsulation has nothing to do with information hiding, only
>> implementation
>> hiding. Encapsulation does not require the use of getters and setters.
>
> You obviously do not understand the concept of encapsulation. Once again
> I suggest you read a good book on it. Booch would be an excellent start.
> However, I suspect it will be way over your head. It's meant for
> programmers.
The definition of encapsulation is "The act of placing data and the
operations that perform on that data in the same class. The class then
becomes the 'capsule' or container for the data and operations." There is
nowhere in that definition which says anything about hiding the data by
setting access to "private", or even setting operations to "private".
<snip>
> Encapsulation has nothing to do with "data hiding". I never said it did.
> But it DOES have EVERYTHING to do with controlling ACCESS to the data.
> Once again, I suggest you read a book by a recognized expert in the field,
> not something on the internet written by someone as incompetent as you.
Access is controlled by changing a property from "public" to "private". If
it is "public" then it can be accessed directly without using a getter or a
setter. If it is "private" then it cannot be accessed directly and therefore
can *ONLY* be accessed using a getter or a setter.
Therefore the use of getters and setters is directly related to the hiding
of data by changing its access from "public" to "private".
Encapsulation does *NOT* mean information hiding, therefore I do *NOT* have
to make all my properties private, therefore I do *NOT* have to use geters
and setters.
<snip>
>>> Your framework generates less code because it's only a half-assed
>>> implementation of even basic OO principles (which you have repeatedly
>>> shown you don't understand).
>>
>> My framework is an implementation of MY understanding of the principles
>> of
>> OOP just as your framework is an implementation of YOUR understanding of
>> the
>> same principles. When you consider the fact that there is no universal
>> agreement on what "Object Oriented Programming" actually means then it is
>> not surprising that two individuals have a totally different
>> understanding.
>> Yet I am not the one who is saying that *MY* understanding is the only
>> opinion worth having.
>
> And your understanding is pure crap. There IS a universal agreement on
> the basic principles of OOP by recognized experts in the field.
There is *NO* universal agreement on what OO is and is not. Take a look at
http://c2.com/cgi/wiki?NobodyAgreesOnWhatOoIs if you don't believe me.
>> Take a look at these articles to see if you can identify a definition of
>> OOP
>> with is universally accepted:
>>
>> http://c2.com/cgi/wiki?DefinitionsForOo
>> http://c2.com/cgi/wiki?NobodyAgreesOnWhatOoIs
>> http://www.devx.com/opinion/Article/26776
>> http://www.geocities.com/tablizer/oopbad.htm
>> http://www.geocities.com/tablizer/whypr.htm
>> http://www.geocities.com/tablizer/core1.htm
>> http://www.geocities.com/tablizer/beyondhw.htm
>> http://c2.com/cgi/wiki?ArgumentsAgainstOop
>> http://c2.com/cgi/wiki?ObjectOrientationIsDead
>> http://c2.com/cgi/wiki?ObjectOrientationIsaHoax
>> http://dreamsongs.com/ObjectsHaveFailedNarrative.html
>> http://www.eetimes.com/design/embedded/4216597/Nuts-to-OOP
>> http://c2.com/cgi/wiki?ObjectOrientedForDummies
>
> Once again I urge you to read a book by a recognized expert in the field
> and not something on the internet written by a person who has no
> understanding of what OOP really is.
Oh I see! Only those books or articles which support your twisted view are
the ones worth considering! How arrogant you are!
There are thousands of books and articles which have been written about
programming in general and OO programming in particular, yet there is no
single set of "rules" which have been accepted by everyone. It is impossible
to follow every set of rules that has ever been published, so I choose to
follow only those rules which seem sensible to me.
> Which of those are your articles, BTW?
None. They were written by others who are also not impressed with some of
the rubbish ideas that have somehow been turned into "rules".
<snip>
>>>> You so are saying that I'm incompetent simply because I refuse to
>>>> follow
>>>> YOUR rules? Do you know how arrogant that makes you?
>>>
>>> No, widely recognized rules by experts.
>>
>> Who says that the rules that you choose to follow were written by
>> experts?
>> What about different sets of rules written by different sets of experts?
>
> There are world-wide recognized experts like Booch in the field who agree
> on the same rules. Show me any world-wide experts who support your
> "rules". And someone with a blog on the internet doesn't count.
There are plenty of "experts" out there who agree on different sets of
rules. There is no single set of rules which is universally followed by
*all* experts.
I just happen to follow a different set of rules which are favoured by a
different set of experts.
Of course you are so arrogant you will no doubt say that the experts that I
follow are wrong while the experts that you follow are the only experts
worth listening to.
--
Tony Marston
http://www.tonymarston.net
http://www.radicore.org
|
|
|
|
| Re: [OT] Was: Dynamic form generation [message #177919 is a reply to message #177908] |
Fri, 27 April 2012 08:26 |
Erwin Moller
Messages: 228
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 4/26/2012 1:51 PM, Tony Marston wrote:
> "Erwin Moller"<erwinmollerusenet(at)xs4all(dot)nl> wrote in message
> news:4f97de59$0$6976$e4fe514c(at)news2(dot)news(dot)xs4all(dot)nl...
>> On 4/24/2012 11:10 AM, Thomas 'PointedEars' Lahn wrote:
>>> It is a yes-or-no question, therefore it cannot be incorrect.
>>
>> Yes, even yes-or-no questions can be incorrect, in the sense that both
>> "yes" and "no" are incorrect answers.
>>
>> Here is an example:
>> "This sentence is not true. Is the former sentence correct? Yes or no?"
>
> Your example is irrelevant.
Of course.
Hence the added "OT" to the thread subject.
OT means "Off Topic".
"Off Topic" means I am aware I am adding something that isn't relevant
to the discussion.
Maybe you don't know what OT means. Maybe you didn't see it in the subject?
Why did I add OT? I didn't want to get involved in the discussion itself
(but which I am reading with interest).
And I was responding to Thomas Lahn, who stated that a yes-or-no
question cannot be incorrect, which is not always true.
Lahn: "It is a yes-or-no question, therefore it cannot be incorrect."
This is a technical newsgroup for programmers.
IMHO ALL programmers should at least be mildly interested in the example
I gave, and its implications.
Regards,
Erwin Moller
--
"That which can be asserted without evidence, can be dismissed without
evidence."
-- Christopher Hitchens
|
|
|
|
| Re: Dynamic form generation [message #177920 is a reply to message #177888] |
Fri, 27 April 2012 08:52 |
Tony Marston
Messages: 57
Registered: November 2010
Karma: 0
|
Member |
|
|
"Jerry Stuckle" <jstucklex(at)attglobal(dot)net> wrote in message
news:jn8r0c$iss$1(at)dont-email(dot)me...
>> I can accept criticism in the form of "you do it that way, but wouldn't
>> this
>> way be better?", but all you sem to do is state time and timer again
>> "your
>> way is different from mine, therefore it must be crap".
>
> No, you can't. I've tried to tell you which ways are better, as indicated
> by world-recognized experts. But you're too stoopid to understand. You
> won't even pick up a book by one of those experts.
You have never asked the question "Do you think that *this* way is better?"
you have simply said "Your way is wrong! You *MUST* do it *MY* way!" That is
not giving me "advice", that is giving me an order!
If you give me advice then I may consider it, but if you give me an order
then I will ignore it.
As for *your* favourite experts - there is no such thing as a single set of
experts with whom everybody agrees. There are millions of books and millions
of articles on the subject of programming written by millins of authors. Who
is to say which of those is an "expert" and who is not?
In my long career I have read many books and many articles, and have worked
of many pieces of code written in many different ways by many different
programmers. I have seen good code and I have seen bad code. I have seen
coding styles that I agree with and try to emulate, and coding styles that I
disagree with and avoid like the plague.
Whenever I see a piece of code or read a book or article on how code should
be written I take that as "advice" and not an "order". Sometimes I agree
with what I read, but sometimes I disagree. I will *ONLY* follow those
practices with which I agree, and I will ignore those practices with which I
do not agree. If you are te kind of programmer who says "I have just read
this in a book, so I *MUST* follow it without question" then you are an
idiot. I evaluate everything I read, and if I don't like it then I don't use
it.
>> I would always welcome suggestions to improve my code, but by "improve" I
>> do
>> *NOT* mean "make it the same as mine". If I did everything the same as
>> you
>> then I would be no better than you, and I'm afraid that your best is not
>> good enough.
>
> No, you don't. All you do is defend your crap, which goes against many
> recognized good practices.
I repeat, there is no such thing as a single set of practices which are
universally recognised by *ALL* programmers. I don't follow your favourite
practices just as you don't follow mine. We agree to disagree, so leave it
at that.
>> The fact that my methods of achieving a result are different from yours
>> does
>> not make my methods "wrong", only "different". They work, therefore they
>> are
>> not wrong.
>
> The fact you don't even understand basic concepts like encapsulation makes
> your code crap.
It is *your* definition of encapsulation which is twisted, not mine.
Encasulaton does *NOT* require that all properties are private, and it does
*NOT* require that all values are manipulated via getters and setters.
>> You have not provided any code samples that demonstrate that your methods
>> are superior, so why should I or anyone else believe that your methods
>> are
>> superior? Just be cause you say so?
>
> I don't need to. I've told you show it should be done (i.e. private
> variables, setters/getters, etc.). But you've discounted all of that.
Private variables and getters/setters are *NOT* a requirement of
encapsulation.
> Read some books by world-recognized experts. But I know that's beyond
> your comprehension. The only thing you'll read is someone who agrees with
> you on the internet.
>
> But I'm tired of trying to teach a pig to sing. You can have the last
> word. Idiots need that.
You should realise that you can't teach a pig to sing just as you can't
teach a fish to ride a bicycle.
You will never teach me to program the way that you do for the simple reason
that it would be a giant step backwards. If I did everything the same as you
then I would be no better tan you, and I'm afraid that your best is simply
not good enough.
--
Tony Marston
http://www.tonymarston.net
http://www.radicore.org
|
|
|
|
| Re: Dynamic form generation [message #177925 is a reply to message #177888] |
Fri, 27 April 2012 13:16 |
Tony Marston
Messages: 57
Registered: November 2010
Karma: 0
|
Member |
|
|
"Jerry Stuckle" <jstucklex(at)attglobal(dot)net> wrote in message
news:jn8r0c$iss$1(at)dont-email(dot)me...
<snip>
> The fact you don't even understand basic concepts like encapsulation makes
> your code crap.
It is *YOUR* understanding of encapsulation which is flawed, not mine. You
seem to think that there are only two ways of putting data into an object:
(1) Using a publicly accessible variable, as in $object->foo = 'bar';
(2) Making the variable "private" and using a setter, as in
$object->setFoo('bar');
You are totally blind to the 3rd option which is:
(3) Inject data via a method's argument, as in
$object->insertRecord($_POST);
Don't forget that $_POST is an array which can contain any number of values,
or even arrays of values. I can just as easily use the $_GET array, or even
an array which is created within another object. How the array is created is
irrelevant.
As $object represents a database table all the data going in and coming out
is a single array variable which can contain either any number of columns,
or any number of rows and columns. When data is passed around internally,
such as through the validation object, it is also passed in as a single
array variable. This means that I never have to unpick the array and use
separate setters for each component within the array.
Encapsulation is nothing more than: "The act of placing data and the
operations that perform on that data in the same class."
There is *NO* rule in the definition of encapsulation which says that I
*MUST* make all the properties private. That is "information hiding", not
"implementation hiding", and encapsulation was *NEVER* meant to mean
information hiding. Even Martin Fowler, the author of Patterns of Enterprise
Application Architecture says so. Is he not considered to be an "expert" in
your eyes?
There is *NO* rule in the definition of encapsulation which says that I
*MUST* inject data one value at a time using a separate setter method. If I
want to inject a collection of data as a single array then there is no rule
which says that I can't. If I want to inject the data as an argument on a
method call then there is no rule which says that I can't.
--
Tony Marston
http://www.tonymarston.net
http://www.radicore.org
|
|
|
|
| [OT] Yes-or-no questions (was: [OT] Was: Dynamic form generation) [message #177936 is a reply to message #177908] |
Sat, 28 April 2012 05:56 |
Thomas 'PointedEars'
Messages: 701
Registered: October 2010
Karma: 0
|
Senior Member |
|
|
Tony Marston wrote:
> "Erwin Moller" [wrote]:
>> On 4/24/2012 11:10 AM, Thomas 'PointedEars' Lahn wrote:
>>> It is a yes-or-no question, therefore it cannot be incorrect.
>>
>> Yes, even yes-or-no questions can be incorrect, in the sense that both
>> "yes" and "no" are incorrect answers.
>>
>> Here is an example:
>> "This sentence is not true. Is the former sentence correct? Yes or no?"
>
> Your example is irrelevant.
It is not irrelevant, but it is wrong. A yes-or-no question that cannot be
answered with a simple "yes" or "no" is _not_ incorrect. But it is harder
to answer. It also *might* indicate a fallacy, in which latter case the Zen
masters have given us the word "mu" to avoid a wrong answer.
> The original statement came in 2 parts:
> (1) "This means that you perform no type conversion or checking, or range
> checking in the application."
> followed by the question
> (2) "yes?".
>
> The question (2) I read as "is the statement (1) correct or incorrect?" to
> which I answered "incorrect".
And there you are wrong. It was _not_ a statement, it was a *question*.
Statements end with a period. Questions end with a question mark. This
sentence ended with a question mark. A reasonable answer to that question,
since it was a yes-or-no question, would have started with "Yes" or "No" or
be a statement having these words as bottom line. But _not_ "Correct" or
"Incorrect". I concede that it was a suggestive question, but that does not
make it incorrect.
The way the Subject header field was changed here is inappropriate. For a
start, it is insufficient to tag a posting as off-topic; the new topic needs
to be provided as well. The common, reasonable and accepted change is
described at <http://www.netmeister.org/news/learn2quote.html>. There you
(Tony) will also find a description on the attribution that you are still
ignoring.
F'up2 poster
PointedEars
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann
|
|
|
|
| Re: What Jerry Stuckle thinks of PHP programmers [message #177937 is a reply to message #177866] |
Sat, 28 April 2012 07:48 |
Tony Marston
Messages: 57
Registered: November 2010
Karma: 0
|
Member |
|
|
"Thomas 'PointedEars' Lahn" wrote in message
news:1507037(dot)RFmFTntJpl(at)PointedEars(dot)de...
>
> Tony Marston wrote:
>> No, you assume that I'm incompetent because I have the balls to disagree
>> with you.
>
> I am afraid that in your case it is your bold and wrong statements about
> (PHP) programming that show you as being inexperienced at least.
My statements about PHP programming are not wrong for the simple reason that
they work, and anybody with more than two brain cells to rub together should
know that something which works cannot be wrong just as something which does
not work cannot be right.
The argument from Jerry Stuckle is simple "You are not doing it the same way
as me, therefore you are wrong!"
I am not doing it the same way as Jerry Stuckle because I prefer a different
way, a better way.
--
Tony Marston
http://www.tonymarston.net
http://www.radicore.org
|
|
|
|
| Re: What Jerry Stuckle thinks of PHP programmers [message #177938 is a reply to message #177937] |
Sat, 28 April 2012 08:23 |
The Natural Philosoph
Messages: 993
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
Tony Marston wrote:
> "Thomas 'PointedEars' Lahn" wrote in message
> news:1507037(dot)RFmFTntJpl(at)PointedEars(dot)de...
>>
>> Tony Marston wrote:
>>> No, you assume that I'm incompetent because I have the balls to disagree
>>> with you.
>>
>> I am afraid that in your case it is your bold and wrong statements about
>> (PHP) programming that show you as being inexperienced at least.
>
> My statements about PHP programming are not wrong for the simple reason
> that they work, and anybody with more than two brain cells to rub
> together should know that something which works cannot be wrong just as
> something which does not work cannot be right.
>
> The argument from Jerry Stuckle is simple "You are not doing it the same
> way as me, therefore you are wrong!"
>
> I am not doing it the same way as Jerry Stuckle because I prefer a
> different way, a better way.
>
What makes you think Jerry actually writes any code at all, ever?
I have seen no evidence of it.
All I ever found was that he had a training company once, that no longer
generates any revenue.
--
To people who know nothing, anything is possible.
To people who know too much, it is a sad fact
that they know how little is really possible -
and how hard it is to achieve it.
|
|
|
|
| Re: What Jerry Stuckle thinks of PHP programmers [message #177940 is a reply to message #177938] |
Sat, 28 April 2012 12:37 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 4/28/2012 4:23 AM, The Natural Philosopher wrote:
> Tony Marston wrote:
>> "Thomas 'PointedEars' Lahn" wrote in message
>> news:1507037(dot)RFmFTntJpl(at)PointedEars(dot)de...
>>>
>>> Tony Marston wrote:
>>>> No, you assume that I'm incompetent because I have the balls to
>>>> disagree
>>>> with you.
>>>
>>> I am afraid that in your case it is your bold and wrong statements about
>>> (PHP) programming that show you as being inexperienced at least.
>>
>> My statements about PHP programming are not wrong for the simple
>> reason that they work, and anybody with more than two brain cells to
>> rub together should know that something which works cannot be wrong
>> just as something which does not work cannot be right.
>>
>> The argument from Jerry Stuckle is simple "You are not doing it the
>> same way as me, therefore you are wrong!"
>>
>> I am not doing it the same way as Jerry Stuckle because I prefer a
>> different way, a better way.
>>
> What makes you think Jerry actually writes any code at all, ever?
>
> I have seen no evidence of it.
>
> All I ever found was that he had a training company once, that no longer
> generates any revenue.
>
ROFLMAO! How you wish! I made more money last week than you have all
year. Of course, you admit you're "semi-retired" - because you can't
find a job.
I've never seen any of the code you've "written". That's because you
never have written any.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: What Jerry Stuckle thinks of PHP programmers [message #177941 is a reply to message #177937] |
Sat, 28 April 2012 12:46 |
Thomas 'PointedEars'
Messages: 701
Registered: October 2010
Karma: 0
|
Senior Member |
|
|
Tony Marston wrote:
> "Thomas 'PointedEars' Lahn" wrote in message
> news:1507037(dot)RFmFTntJpl(at)PointedEars(dot)de...
Will you ever learn to post?
>> Tony Marston wrote:
>>> No, you assume that I'm incompetent because I have the balls to disagree
>>> with you.
>>
>> I am afraid that in your case it is your bold and wrong statements about
>> (PHP) programming that show you as being inexperienced at least.
>
> My statements about PHP programming are not wrong for the simple reason
> that they work,
Your logic is flawed. Even things that are objectively wrong to do may
appear to work in simple cases.
> and anybody with more than two brain cells to rub together should know
> that something which works cannot be wrong just as something which does
> not work cannot be right.
But people with a lot more than two brain cells to rub together know that
"it works (now)" has never been a good criterion for code quality.
> The argument from Jerry Stuckle is simple "You are not doing it the same
> way as me, therefore you are wrong!"
No, I don't think so.
> I am not doing it the same way as Jerry Stuckle because I prefer a
> different way, a better way.
You are preferring a different way, but not necessarily a better way. In
fact, it has been showed to you more than once that your way – in favor of
which you have provided no arguments other than "I don't care" – has a
number of shortcomings that the "traditional" way, if you want to call it
that, does not have.
You are just refusing to accept that because, in your humble opinion, it
does not matter. But in any non-trivial piece of code, especially in code
that is not used by only one person, it does matter.
BTW, pi's Law. You lose.
PointedEars
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]