| out of sheer curiosity... [message #177422] |
Tue, 27 March 2012 17:01  |
Leonardo Azpurua
Messages: 46
Registered: December 2010
Karma: 0
|
Member |
|
|
Is there any good reason for not implementing the dot as a member selector
for objects?
i.e. instead of $object->memberFunction(...), just
$object.memberFunction(...)
Jumping back and forth between javaScript and PHP (which I guess is a common
situation for PHP developers) makes it easy to use dots when arrows should
be used, and viceversa.
Regards.
--
|
|
|
|
| Re: out of sheer curiosity... [message #177423 is a reply to message #177422] |
Tue, 27 March 2012 17:06  |
alvaro.NOSPAMTHANX
Messages: 277
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
El 27/03/2012 19:01, Leonardo Azpurua escribió/wrote:
> Is there any good reason for not implementing the dot as a member selector
> for objects?
Because it's already the concatenation operator:
>
> i.e. instead of $object->memberFunction(...), just
> $object.memberFunction(...)
.... and will break backwards compatibility at syntax level:
<?php
function memberFunction(){
return 'Hi!';
}
class Foo{
public function __toString(){
return '(foo)';
}
}
$object = new Foo;
echo $object.memberFunction(); // We are concatenating!
--
-- http://alvaro.es - Álvaro G. Vicario - Burgos, Spain
-- Mi sitio sobre programación web: http://borrame.com
-- Mi web de humor satinado: http://www.demogracia.com
--
|
|
|
|
| Re: out of sheer curiosity... [message #177425 is a reply to message #177423] |
Tue, 27 March 2012 17:34 |
Leonardo Azpurua
Messages: 46
Registered: December 2010
Karma: 0
|
Member |
|
|
(slapping my own forehead) Of course!
The __toString() thing was also useful.
I whish I had time to read the manual from cover to cover.
Thanks.
""lvaro G. Vicario"" <alvaro(dot)NOSPAMTHANX(at)demogracia(dot)com(dot)invalid> escribi
en el mensaje news:jkss34$trc$1(at)dont-email(dot)me...
> El 27/03/2012 19:01, Leonardo Azpurua escribi/wrote:
>> Is there any good reason for not implementing the dot as a member
>> selector
>> for objects?
>
> Because it's already the concatenation operator:
>
>>
>> i.e. instead of $object->memberFunction(...), just
>> $object.memberFunction(...)
>
> ... and will break backwards compatibility at syntax level:
>
> <?php
>
> function memberFunction(){
> return 'Hi!';
> }
>
> class Foo{
> public function __toString(){
> return '(foo)';
> }
> }
>
> $object = new Foo;
> echo $object.memberFunction(); // We are concatenating!
>
>
>
> --
> -- http://alvaro.es - lvaro G. Vicario - Burgos, Spain
> -- Mi sitio sobre programacin web: http://borrame.com
> -- Mi web de humor satinado: http://www.demogracia.com
> --
|
|
|
|
| Re: out of sheer curiosity... [message #177426 is a reply to message #177422] |
Wed, 28 March 2012 19:12 |
Thomas 'PointedEars'
Messages: 701
Registered: October 2010
Karma: 0
|
Senior Member |
|
|
Leonardo Azpurua wrote:
> Is there any good reason for not implementing the dot as a member selector
> for objects?
Perhaps to have a separate operator for string concatenation?
> i.e. instead of $object->memberFunction(...), just
> $object.memberFunction(...)
>
> Jumping back and forth between javaScript and PHP (which I guess is a
> common situation for PHP developers)
There is no `javaScript'. [1a, 1b] However, you may have observed that
(barring String and Array methods) you need to use the `+' operator both for
addition and string concatenation in ECMAScript implementations [2].
Because those languages are loosely and dynamically typed [3], that has
turned out to be a disadvantage as it is a frequent problem (not only for
beginners) there, especially with calculation in Web forms (where all
control values are strings [4]). In PHP you get implicit conversion to a
numeric type with the `+' operator, and implicit conversion to string with
the `.' operator. [5] In PHP, '1' + 2 will never result in '12' as it will
in ECMAScript.
In order to complement Java [6, 7], Netscape JavaScript needed to be Java-
like; PHP did not. So only with the former, the `.' punctuator was already
taken for property access. That propagated from JavaScript 1.1 (at the
latest) to Microsoft JScript 1.0, therefore to the ECMAScript Language
Specification whose first edition was based on both languages [8], and
naturally to later ECMAScript implementations.
> makes it easy to use dots when arrows should be used, and viceversa.
Programming becomes a lot easier when you accept the fact that there are
different programming languages with different syntaxes and sets of
paradigms that are supported. Do not try (as a programmer) to make one
programming look or work like another; try to leverage the advantages of
each programming language instead.
Indeed, with PHP code and code written in/for ECMAScript implementations
often being used in the same file but *usually* executed in different
runtime environments (PHP: server-side; ECMAScript implementations: client-
side), and supporting by default different sets of programming paradigms and
inheritance types (PHP: procedural-imperative, object-oriented with class-
based inheritance, partially functional¹; ECMAScript implementations:
procedural-imperative, object-oriented with prototype-based inheritance,
fully functional¹) it is good that their syntax does not look the same, as
the different syntax is helpful in telling them apart.
HTH
PointedEars
___________
¹ supporting lambda calculus, like e.g. Lisp or Haskell
References:
[1a] Lahn, Thomas (2011-08-21). ECMAScript Support Matrix.
<http://PointedEars.de/scripts/test/es-matrix/>.
[1b] Lahn, Thomas (2012). Features von ECMAScript-basierten
Programmiersprachen – Eine vergleichende Analyse. BSc SUPSI.
Fernfachhochschule Schweiz (FFHS).
[2] Ecma International (2011-06). Standard ECMA-262. ECMAScript Language
Specification. 5.1 Edition.
<http://www.ecma-international.org/publications/files/
ECMA-ST/Ecma-262.pdf> (accessed 2011-08-27). Section 11.6.1.
[3] ibid., section 8.
[4] World Wide Web Consortium (2003). Document Object Model (DOM) Level
2 HTML Specification. Version 1.0. Appendix D: ECMAScript Language
Binding.
<http://www.w3.org/TR/DOM-Level-2-HTML/ecma-script-binding.html>
(accessed 2012-03-28).
[5] The PHP Documentation Group (2012). PHP Manual. Operators.
<http://php.net/operators> (accessed 2012-03-28).
[6] Krill, Paul (2008-06-23). „JavaScript creator ponders past, future“.
In: InfoWorld. Developer World.
<http://www.infoworld.com/d/developer-world/
javascript-creator-ponders-past-future-704> (accessed 2011-12-22).
[7] Hamilton, Naomi (2008-07-31). „The A-Z of Programming Languages:
JavaScript“. In: Computerworld. The A-Z of Programming Languages.
<http://www.computerworld.com.au/article/255293/a-z_programming_
languages_javascript/> (accessed 2011-12-31).
[8] Ecma International (June 1997). Standard ECMA-262 – ECMAScript: A
general-purpose, cross-platform programming language.
<http://www.mozilla.org/js/language/E262.pdf (accessed 2003-12-15).
p. 2.
--
When all you know is jQuery, every problem looks $(olvable).
|
|
|
|
| Re: out of sheer curiosity... [message #177427 is a reply to message #177426] |
Thu, 29 March 2012 00:53 |
Leonardo Azpurua
Messages: 46
Registered: December 2010
Karma: 0
|
Member |
|
|
"Thomas 'PointedEars' Lahn" <PointedEars(at)web(dot)de> escribi en el mensaje
news:17777949(dot)TfjZNtg3zH(at)PointedEars(dot)de...
> Programming becomes a lot easier when you accept the fact that there are
> different programming languages with different syntaxes and sets of
> paradigms that are supported. Do not try (as a programmer) to make one
> programming look or work like another; try to leverage the advantages of
> each programming language instead.
Good explanation and best advice.
Thanks!
--
|
|
|
|
| Re: out of sheer curiosity... [message #177428 is a reply to message #177427] |
Thu, 29 March 2012 08:00 |
M. Strobel
Messages: 386
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
Am 29.03.2012 02:53, schrieb Leonardo Azpurua:
> "Thomas 'PointedEars' Lahn" <PointedEars(at)web(dot)de> escribió en el mensaje
> news:17777949(dot)TfjZNtg3zH(at)PointedEars(dot)de...
>> Programming becomes a lot easier when you accept the fact that there are
>> different programming languages with different syntaxes and sets of
>> paradigms that are supported. Do not try (as a programmer) to make one
>> programming look or work like another; try to leverage the advantages of
>> each programming language instead.
>
> Good explanation and best advice.
>
> Thanks!
>
> --
Yes, this was truly an article.
Next problem (or assignment) is to understand the supported paradigms, and how to use
them to meet your requirements.
I think of the - real or felt? - large ignorance of OO programming in PHP.
/Str.
|
|
|
|
| Re: out of sheer curiosity... [message #177429 is a reply to message #177428] |
Thu, 29 March 2012 09:53 |
Leonardo Azpurua
Messages: 46
Registered: December 2010
Karma: 0
|
Member |
|
|
"M. Strobel" <sorry_no_mail_here(at)nowhere(dot)dee> escribi en el mensaje
news:9tij5fFmi8U1(at)mid(dot)uni-berlin(dot)de...
> Yes, this was truly an article.
>
> Next problem (or assignment) is to understand the supported paradigms,
> and how to use them to meet your requirements.
>
> I think of the - real or felt? - large ignorance of OO programming in PHP.
Probably felt.
I mean, I am ignorant of much of PHP. But its support for OOP is quite
standard: single inheritance, interfaces, private, public and protected
visibility, abstract vs. concrete classes and methods. The "magic methods"
which I just discovered thanks to Alvaro Vicario's response to my original
post are sort of "idiosincratic", but perfectly understandable. It lacks
operator overloading (which I have never actually used) and signature based
overloading (which might come handy, but would probably conflict with the
dynamic nature of PHP function calls, which I certainly prefer).
I have been using (crippled) OO languages for the last couple of decades,
and my analisys and design methods are purely OO.
My ignorance of PHP is absolute, not just OO related.
--
|
|
|
|
| Re: out of sheer curiosity... [message #177430 is a reply to message #177429] |
Thu, 29 March 2012 10:46 |
The Natural Philosoph
Messages: 993
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
Leonardo Azpurua wrote:
> "M. Strobel" <sorry_no_mail_here(at)nowhere(dot)dee> escribi� en el mensaje
> news:9tij5fFmi8U1(at)mid(dot)uni-berlin(dot)de...
>
>> Yes, this was truly an article.
>>
>> Next problem (or assignment) is to understand the supported paradigms,
>> and how to use them to meet your requirements.
>>
>> I think of the - real or felt? - large ignorance of OO programming in PHP.
>
>
> Probably felt.
>
> I mean, I am ignorant of much of PHP. But its support for OOP is quite
> standard: single inheritance, interfaces, private, public and protected
> visibility, abstract vs. concrete classes and methods. The "magic methods"
> which I just discovered thanks to Alvaro Vicario's response to my original
> post are sort of "idiosincratic", but perfectly understandable. It lacks
> operator overloading (which I have never actually used) and signature based
> overloading (which might come handy, but would probably conflict with the
> dynamic nature of PHP function calls, which I certainly prefer).
>
> I have been using (crippled) OO languages for the last couple of decades,
> and my analisys and design methods are purely OO.
>
Do you know, I don't even know when my analysis and design methods are
OO and when they are not.
Its just another way of doing things and I let my understanding of the
problem guide me, not a set of arbitrary rules.
I dont use OOP languages, because having read up on them extensively
when they first appeared I simply thought 'oh, ok, I see where they are
coming from' and incorporated a few ideas about how code and data should
be organised in pseudo object form, and moved on. The benefits are in
the way of looking at things, not enforcing a set of strictures on
programming. Especially when many coding problems do not lend themselves
to those strictures.
(and almost all of the problems to which PHP is the natural language of
choice do not benefit from OOP. If a web site is the application each
php 'page' is an object in its own right..anyway. Neither are
microprocessors in the end object oriented. Object orientation stresses
the structure of data, whereas procedural coding stresses the way in
which processing is carried out.)
> My ignorance of PHP is absolute, not just OO related.
>
> --
>
>
--
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: out of sheer curiosity... [message #177431 is a reply to message #177430] |
Thu, 29 March 2012 12:02 |
M. Strobel
Messages: 386
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
Am 29.03.2012 12:46, schrieb The Natural Philosopher:
> Leonardo Azpurua wrote:
>> "M. Strobel" <sorry_no_mail_here(at)nowhere(dot)dee> escribi� en el mensaje
>> news:9tij5fFmi8U1(at)mid(dot)uni-berlin(dot)de...
>>
>>> Yes, this was truly an article.
>>>
>>> Next problem (or assignment) is to understand the supported paradigms,
>>> and how to use them to meet your requirements.
>>>
>>> I think of the - real or felt? - large ignorance of OO programming in PHP.
>>
>>
>> Probably felt.
>>
>> I mean, I am ignorant of much of PHP. But its support for OOP is quite standard:
>> single inheritance, interfaces, private, public and protected visibility, abstract
>> vs. concrete classes and methods. The "magic methods" which I just discovered
>> thanks to Alvaro Vicario's response to my original post are sort of
>> "idiosincratic", but perfectly understandable. It lacks operator overloading (which
>> I have never actually used) and signature based overloading (which might come
>> handy, but would probably conflict with the dynamic nature of PHP function calls,
>> which I certainly prefer).
>>
>> I have been using (crippled) OO languages for the last couple of decades, and my
>> analisys and design methods are purely OO.
>>
>
> Do you know, I don't even know when my analysis and design methods are OO and when
> they are not.
>
> Its just another way of doing things and I let my understanding of the problem guide
> me, not a set of arbitrary rules.
>
> I dont use OOP languages, because having read up on them extensively when they first
> appeared I simply thought 'oh, ok, I see where they are coming from' and incorporated
> a few ideas about how code and data should be organised in pseudo object form, and
> moved on. The benefits are in the way of looking at things, not enforcing a set of
> strictures on programming. Especially when many coding problems do not lend
> themselves to those strictures.
>
> (and almost all of the problems to which PHP is the natural language of choice do not
> benefit from OOP. If a web site is the application each php 'page' is an object in
> its own right..anyway. Neither are microprocessors in the end object oriented.
> Object orientation stresses the structure of data, whereas procedural coding
> stresses the way in which processing is carried out.)
This is exactly what I mean: how does the OO concept help me?
You could compare it maybe to languages: there is the passive and the active
knowledge, passive means you understand (some), active means you talk (some).
Understanding what someone says is far easier than saying it yourself.
You must get to talk OO - or whatever the concept is. I only learned talking OO after
attending some Java courses, and I already had 10 years of IT experience then.
/Str.
|
|
|
|
| Re: out of sheer curiosity... [message #177432 is a reply to message #177430] |
Thu, 29 March 2012 12:33 |
Erwin Moller
Messages: 228
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 3/29/2012 12:46 PM, The Natural Philosopher wrote:
> Leonardo Azpurua wrote:
>> "M. Strobel" <sorry_no_mail_here(at)nowhere(dot)dee> escribi� en el mensaje
>> news:9tij5fFmi8U1(at)mid(dot)uni-berlin(dot)de...
>>
>>> Yes, this was truly an article.
>>>
>>> Next problem (or assignment) is to understand the supported paradigms,
>>> and how to use them to meet your requirements.
>>>
>>> I think of the - real or felt? - large ignorance of OO programming in
>>> PHP.
>>
>>
>> Probably felt.
>>
>> I mean, I am ignorant of much of PHP. But its support for OOP is quite
>> standard: single inheritance, interfaces, private, public and
>> protected visibility, abstract vs. concrete classes and methods. The
>> "magic methods" which I just discovered thanks to Alvaro Vicario's
>> response to my original post are sort of "idiosincratic", but
>> perfectly understandable. It lacks operator overloading (which I have
>> never actually used) and signature based overloading (which might come
>> handy, but would probably conflict with the dynamic nature of PHP
>> function calls, which I certainly prefer).
>>
>> I have been using (crippled) OO languages for the last couple of
>> decades, and my analisys and design methods are purely OO.
>>
>
> Do you know, I don't even know when my analysis and design methods are
> OO and when they are not.
Erm... seriously TNP?
Hint: If you use words like 'class' and 'new' you are typically in OO.
If you use functions outside a class you are typically procedural.
I think you know.
>
> Its just another way of doing things and I let my understanding of the
> problem guide me, not a set of arbitrary rules.
As it should!
But what 'rules' are you referring to?
PHP's OO is pretty straightforward.
I think they did a decent job implementing OO.(php 5 that is)
Creating smart classes is up to the programmer.
I am not aware of any extra 'rules'.
Are you maybe referring to all kinds of design patterns scattered around
the web?
(In which case I tend to agree, because implementing other people's
solutions can take the fun out of programming. But reading them never
hurts. And when you agree to a certain approach you can even decide to
follow it yourself. It is all up to you, the programmer.)
>
> I dont use OOP languages, because having read up on them extensively
> when they first appeared I simply thought 'oh, ok, I see where they are
> coming from' and incorporated a few ideas about how code and data should
> be organised in pseudo object form, and moved on. The benefits are in
> the way of looking at things, not enforcing a set of strictures on
> programming. Especially when many coding problems do not lend themselves
> to those strictures.
True, but also a truism.
"If a certain problem is unfit for OO approach, it is unfit for OO
approach."
But even then, OO often won't hurt too much either.
You can simply use your procedural logic in OO too.
I worked like that in Java when I started learning the language, until I
discovered how idiotic I was. All part of the learning curve. :-)
>
> (and almost all of the problems to which PHP is the natural language of
> choice do not benefit from OOP. If a web site is the application each
> php 'page' is an object in its own right..anyway.
True for a simple plain webpage, but when you have something more
complex OO can certainly help.
Most (all?) modern MVC software are at least partly OO, simply because
it makes things easier to organize.
With OO you don't have to drag all the information around to each
function that (might) need it. And scope is better organized: more
intuitive.
OO makes things easier to organize, that's all, but it DOESN'T define
how to solve your problem at hand.
> Neither are
> microprocessors in the end object oriented. Object orientation stresses
> the structure of data, whereas procedural coding stresses the way in
> which processing is carried out.)
Both true, but I don't think that the exact implementation on some
microprocessor is relevant for >99% of all programmers.
Most programmers have no clue how to code directly for a cpu.
The last microprocessor I coded directly was the 6502.
I have NO IDEA how to code for my current quadcode, and I don't care either.
We have compilers and interpreters and bytecode and what's more to solve
that.
Programmers focus on the task at hand, often in a high level language.
And OO is a very fine addition.
Give it another try one day. :-)
Regards,
Erwin Moller
--
"That which can be asserted without evidence, can be dismissed without
evidence."
-- Christopher Hitchens
|
|
|
|
| Re: out of sheer curiosity... [message #177433 is a reply to message #177432] |
Thu, 29 March 2012 13:37 |
The Natural Philosoph
Messages: 993
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
Erwin Moller wrote:
> On 3/29/2012 12:46 PM, The Natural Philosopher wrote:
>> Leonardo Azpurua wrote:
>>> "M. Strobel" <sorry_no_mail_here(at)nowhere(dot)dee> escribi� en el mensaje
>>> news:9tij5fFmi8U1(at)mid(dot)uni-berlin(dot)de...
>>>
>>>> Yes, this was truly an article.
>>>>
>>>> Next problem (or assignment) is to understand the supported paradigms,
>>>> and how to use them to meet your requirements.
>>>>
>>>> I think of the - real or felt? - large ignorance of OO programming in
>>>> PHP.
>>>
>>>
>>> Probably felt.
>>>
>>> I mean, I am ignorant of much of PHP. But its support for OOP is quite
>>> standard: single inheritance, interfaces, private, public and
>>> protected visibility, abstract vs. concrete classes and methods. The
>>> "magic methods" which I just discovered thanks to Alvaro Vicario's
>>> response to my original post are sort of "idiosincratic", but
>>> perfectly understandable. It lacks operator overloading (which I have
>>> never actually used) and signature based overloading (which might come
>>> handy, but would probably conflict with the dynamic nature of PHP
>>> function calls, which I certainly prefer).
>>>
>>> I have been using (crippled) OO languages for the last couple of
>>> decades, and my analisys and design methods are purely OO.
>>>
>>
>> Do you know, I don't even know when my analysis and design methods are
>> OO and when they are not.
>
> Erm... seriously TNP?
>
> Hint: If you use words like 'class' and 'new' you are typically in OO.
> If you use functions outside a class you are typically procedural.
>
> I think you know.
>
>
>>
>> Its just another way of doing things and I let my understanding of the
>> problem guide me, not a set of arbitrary rules.
>
> As it should!
>
> But what 'rules' are you referring to?
>
> PHP's OO is pretty straightforward.
> I think they did a decent job implementing OO.(php 5 that is)
>
> Creating smart classes is up to the programmer.
> I am not aware of any extra 'rules'.
>
> Are you maybe referring to all kinds of design patterns scattered around
> the web?
> (In which case I tend to agree, because implementing other people's
> solutions can take the fun out of programming. But reading them never
> hurts. And when you agree to a certain approach you can even decide to
> follow it yourself. It is all up to you, the programmer.)
>
>>
>> I dont use OOP languages, because having read up on them extensively
>> when they first appeared I simply thought 'oh, ok, I see where they are
>> coming from' and incorporated a few ideas about how code and data should
>> be organised in pseudo object form, and moved on. The benefits are in
>> the way of looking at things, not enforcing a set of strictures on
>> programming. Especially when many coding problems do not lend themselves
>> to those strictures.
>
> True, but also a truism.
> "If a certain problem is unfit for OO approach, it is unfit for OO
> approach."
>
> But even then, OO often won't hurt too much either.
> You can simply use your procedural logic in OO too.
> I worked like that in Java when I started learning the language, until I
> discovered how idiotic I was. All part of the learning curve. :-)
>
>
>>
>> (and almost all of the problems to which PHP is the natural language of
>> choice do not benefit from OOP. If a web site is the application each
>> php 'page' is an object in its own right..anyway.
>
> True for a simple plain webpage, but when you have something more
> complex OO can certainly help.
> Most (all?) modern MVC software are at least partly OO, simply because
> it makes things easier to organize.
>
> With OO you don't have to drag all the information around to each
> function that (might) need it. And scope is better organized: more
> intuitive.
>
> OO makes things easier to organize, that's all, but it DOESN'T define
> how to solve your problem at hand.
>
>
>
>> Neither are
>> microprocessors in the end object oriented. Object orientation stresses
>> the structure of data, whereas procedural coding stresses the way in
>> which processing is carried out.)
>
> Both true, but I don't think that the exact implementation on some
> microprocessor is relevant for >99% of all programmers.
>
> Most programmers have no clue how to code directly for a cpu.
> The last microprocessor I coded directly was the 6502.
> I have NO IDEA how to code for my current quadcode, and I don't care
> either.
>
> We have compilers and interpreters and bytecode and what's more to solve
> that.
> Programmers focus on the task at hand, often in a high level language.
> And OO is a very fine addition.
> Give it another try one day. :-)
>
>
Oh I use it now and again when forced to - not in PHP because its never
been necessary or helpful for the sort of projects I want to code in php
at all.
Its has its place more in designing C++ GUI apps. But even there huge
chunks have to be written in procedural code. Even if that code is
wrapped as an object..
In short you can code without an OOP language, but you cant code without
a procedural one, even if its only machine code.
And if you cant at least envisage how your code maps to a register set
and program counter and stack - well no wonder the world is full of
bloatware.
> 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: out of sheer curiosity... [message #177434 is a reply to message #177432] |
Thu, 29 March 2012 13:39 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 3/29/2012 8:33 AM, Erwin Moller wrote:
> On 3/29/2012 12:46 PM, The Natural Philosopher wrote:
>> Leonardo Azpurua wrote:
>>> "M. Strobel" <sorry_no_mail_here(at)nowhere(dot)dee> escribi� en el mensaje
>>> news:9tij5fFmi8U1(at)mid(dot)uni-berlin(dot)de...
>>>
>>>> Yes, this was truly an article.
>>>>
>>>> Next problem (or assignment) is to understand the supported paradigms,
>>>> and how to use them to meet your requirements.
>>>>
>>>> I think of the - real or felt? - large ignorance of OO programming in
>>>> PHP.
>>>
>>>
>>> Probably felt.
>>>
>>> I mean, I am ignorant of much of PHP. But its support for OOP is quite
>>> standard: single inheritance, interfaces, private, public and
>>> protected visibility, abstract vs. concrete classes and methods. The
>>> "magic methods" which I just discovered thanks to Alvaro Vicario's
>>> response to my original post are sort of "idiosincratic", but
>>> perfectly understandable. It lacks operator overloading (which I have
>>> never actually used) and signature based overloading (which might come
>>> handy, but would probably conflict with the dynamic nature of PHP
>>> function calls, which I certainly prefer).
>>>
>>> I have been using (crippled) OO languages for the last couple of
>>> decades, and my analisys and design methods are purely OO.
>>>
>>
>> Do you know, I don't even know when my analysis and design methods are
>> OO and when they are not.
>
> Erm... seriously TNP?
>
> Hint: If you use words like 'class' and 'new' you are typically in OO.
> If you use functions outside a class you are typically procedural.
>
> I think you know.
>
You forget who you're talking to, Erwin. TNP is not a programmer, both
by his own admission and by his posts here. It doesn't surprise me he
doesn't think OO is any good. I knew a guy like that when I worked for
IBM back in '90. He "read a book about it and didn't see any advantage
in it". But then he wasn't a programmer, either.
>
>>
>> Its just another way of doing things and I let my understanding of the
>> problem guide me, not a set of arbitrary rules.
>
> As it should!
>
> But what 'rules' are you referring to?
>
> PHP's OO is pretty straightforward.
> I think they did a decent job implementing OO.(php 5 that is)
>
> Creating smart classes is up to the programmer.
> I am not aware of any extra 'rules'.
>
> Are you maybe referring to all kinds of design patterns scattered around
> the web?
> (In which case I tend to agree, because implementing other people's
> solutions can take the fun out of programming. But reading them never
> hurts. And when you agree to a certain approach you can even decide to
> follow it yourself. It is all up to you, the programmer.)
>
Any rules TNP doesn't bother to understand are "arbitrary" in his mind.
He doesn't even like having to follow PHP syntax rules - as he has
also said in the past.
But I disagree that PHP 5's implementation of OO is decent. I think
it's half-assed at best. Truly written by people who have no
understanding of OO. But then that can be said of a lot of PHP.
>>
>> I dont use OOP languages, because having read up on them extensively
>> when they first appeared I simply thought 'oh, ok, I see where they are
>> coming from' and incorporated a few ideas about how code and data should
>> be organised in pseudo object form, and moved on. The benefits are in
>> the way of looking at things, not enforcing a set of strictures on
>> programming. Especially when many coding problems do not lend themselves
>> to those strictures.
>
> True, but also a truism.
> "If a certain problem is unfit for OO approach, it is unfit for OO
> approach."
>
> But even then, OO often won't hurt too much either.
> You can simply use your procedural logic in OO too.
> I worked like that in Java when I started learning the language, until I
> discovered how idiotic I was. All part of the learning curve. :-)
>
I agree - I've seen some things which work better using a procedural
approach. But I've also found the more complicated something gets, the
more appropriate an OO approach becomes.
It's like designing a soap box derby racer vs. an SUV. I'd build a kids
racer out of raw materials. It's small, simple and relatively easy.
However, do you think car manufacturers do it this way? Or do they take
an engine from one model, modify the body style from another, etc.? And
if they don't have the right engine, do they design that as part of the
car? Or do they specify the dimensions, mounting, etc. and separately
design the engine to that specification?
No, they don't have to do it that way - they could design each piece
from the bottom up. And then if they change the seats from bench to
bucket, they might find an interdependency and have to also change spark
plugs.
>
>>
>> (and almost all of the problems to which PHP is the natural language of
>> choice do not benefit from OOP. If a web site is the application each
>> php 'page' is an object in its own right..anyway.
>
> True for a simple plain webpage, but when you have something more
> complex OO can certainly help.
> Most (all?) modern MVC software are at least partly OO, simply because
> it makes things easier to organize.
>
No, a page is not an object. A page is closer to a transactional
application. For instance, the page cannot be reused in another page
without modifications. Objects can.
> With OO you don't have to drag all the information around to each
> function that (might) need it. And scope is better organized: more
> intuitive.
>
> OO makes things easier to organize, that's all, but it DOESN'T define
> how to solve your problem at hand.
>
>
Very true.
>
>> Neither are
>> microprocessors in the end object oriented. Object orientation stresses
>> the structure of data, whereas procedural coding stresses the way in
>> which processing is carried out.)
>
> Both true, but I don't think that the exact implementation on some
> microprocessor is relevant for >99% of all programmers.
>
That's because if it isn't good for microprocessors, it must not be good
for anything, according to TNP.
> Most programmers have no clue how to code directly for a cpu.
> The last microprocessor I coded directly was the 6502.
> I have NO IDEA how to code for my current quadcode, and I don't care
> either.
>
> We have compilers and interpreters and bytecode and what's more to solve
> that.
> Programmers focus on the task at hand, often in a high level language.
> And OO is a very fine addition.
> Give it another try one day. :-)
>
I can code Intel processors - I started back in '82 when the typical PC
had 64K or 128K of RAM (and slow). We needed to do some stuff in 808x
assembler. I still do a little as a hobby (mainly to keep up with it),
but I don't go down to the OS level.
>
> Regards,
> Erwin Moller
>
>
>
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: out of sheer curiosity... [message #177435 is a reply to message #177433] |
Thu, 29 March 2012 13:59 |
Erwin Moller
Messages: 228
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 3/29/2012 3:37 PM, The Natural Philosopher wrote:
<snip>
> Its has its place more in designing C++ GUI apps. But even there huge
> chunks have to be written in procedural code. Even if that code is
> wrapped as an object..
>
Let's go 100% off topic. ;-)
Just curious (that was also the original subject of this thread): How
do you write GUI with C++?
I am studying C++ right now (for hobby) and I mainly looking into QT
because it targets both *nix and Windows.
Regards,
Erwin Moller
--
"That which can be asserted without evidence, can be dismissed without
evidence."
-- Christopher Hitchens
|
|
|
|
| Re: out of sheer curiosity... [message #177436 is a reply to message #177434] |
Thu, 29 March 2012 14:21 |
Erwin Moller
Messages: 228
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 3/29/2012 3:39 PM, Jerry Stuckle wrote:
> On 3/29/2012 8:33 AM, Erwin Moller wrote:
>> On 3/29/2012 12:46 PM, The Natural Philosopher wrote:
<snip>
>>> Its just another way of doing things and I let my understanding of the
>>> problem guide me, not a set of arbitrary rules.
>>
>> As it should!
>>
>> But what 'rules' are you referring to?
>>
>> PHP's OO is pretty straightforward.
>> I think they did a decent job implementing OO.(php 5 that is)
>>
>> Creating smart classes is up to the programmer.
>> I am not aware of any extra 'rules'.
>>
>> Are you maybe referring to all kinds of design patterns scattered around
>> the web?
>> (In which case I tend to agree, because implementing other people's
>> solutions can take the fun out of programming. But reading them never
>> hurts. And when you agree to a certain approach you can even decide to
>> follow it yourself. It is all up to you, the programmer.)
>>
>
> Any rules TNP doesn't bother to understand are "arbitrary" in his mind.
> He doesn't even like having to follow PHP syntax rules - as he has also
> said in the past.
>
> But I disagree that PHP 5's implementation of OO is decent. I think it's
> half-assed at best. Truly written by people who have no understanding of
> OO. But then that can be said of a lot of PHP.
>
Jerry,
What are your main objections to the PHP5's OO approach?
For myself: I must say I love its simplicity.
(Simplicity is a Good Thing in my opinion.)
<snip>
>> But even then, OO often won't hurt too much either.
>> You can simply use your procedural logic in OO too.
>> I worked like that in Java when I started learning the language, until I
>> discovered how idiotic I was. All part of the learning curve. :-)
>>
>
> I agree - I've seen some things which work better using a procedural
> approach. But I've also found the more complicated something gets, the
> more appropriate an OO approach becomes.
>
Exactly. :-)
<snip>
>>>
>>> (and almost all of the problems to which PHP is the natural language of
>>> choice do not benefit from OOP. If a web site is the application each
>>> php 'page' is an object in its own right..anyway.
>>
>> True for a simple plain webpage, but when you have something more
>> complex OO can certainly help.
>> Most (all?) modern MVC software are at least partly OO, simply because
>> it makes things easier to organize.
>>
>
> No, a page is not an object. A page is closer to a transactional
> application. For instance, the page cannot be reused in another page
> without modifications. Objects can.
>
No, of course a page is not an object in the OO meaning.
I was referring to using OO to help building the page.
I wonder: one might defend that storing serialized objects in a session
is object persistence, and that a page is hence also part of it because
it is coupled via sess_id to that object.
Nah.. too farfetched.
(And I never store objects in a session anymore: not worth the trouble
in my opinion.)
<snip>
>
> I can code Intel processors - I started back in '82 when the typical PC
> had 64K or 128K of RAM (and slow). We needed to do some stuff in 808x
> assembler. I still do a little as a hobby (mainly to keep up with it),
> but I don't go down to the OS level.
>
Nice!
And I feel like a relic now with my 6502 hands-on experience. ;-)
Regards,
Erwin Moller
--
"That which can be asserted without evidence, can be dismissed without
evidence."
-- Christopher Hitchens
|
|
|
|
| Re: out of sheer curiosity... [message #177437 is a reply to message #177435] |
Thu, 29 March 2012 16:58 |
The Natural Philosoph
Messages: 993
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
Erwin Moller wrote:
> On 3/29/2012 3:37 PM, The Natural Philosopher wrote:
>
> <snip>
>
>> Its has its place more in designing C++ GUI apps. But even there huge
>> chunks have to be written in procedural code. Even if that code is
>> wrapped as an object..
>>
>
> Let's go 100% off topic. ;-)
>
> Just curious (that was also the original subject of this thread): How
> do you write GUI with C++?
> I am studying C++ right now (for hobby) and I mainly looking into QT
> because it targets both *nix and Windows.
>
I am using the GTK toolkit.
Because what I wanted to do would be on a gnomeish platform, and its teh
easy way to do that.
I think a windows version exists.
But its more of an adventure in design than a serious project at this time.
> 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: out of sheer curiosity... [message #177438 is a reply to message #177436] |
Thu, 29 March 2012 17:09 |
The Natural Philosoph
Messages: 993
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
Erwin Moller wrote:
> On 3/29/2012 3:39 PM, Jerry Stuckle wrote:
>> On 3/29/2012 8:33 AM, Erwin Moller wrote:
>>> On 3/29/2012 12:46 PM, The Natural Philosopher wrote:
>
> <snip>
>
>>>> Its just another way of doing things and I let my understanding of the
>>>> problem guide me, not a set of arbitrary rules.
>>>
>>> As it should!
>>>
>>> But what 'rules' are you referring to?
>>>
>>> PHP's OO is pretty straightforward.
>>> I think they did a decent job implementing OO.(php 5 that is)
>>>
>>> Creating smart classes is up to the programmer.
>>> I am not aware of any extra 'rules'.
>>>
>>> Are you maybe referring to all kinds of design patterns scattered around
>>> the web?
>>> (In which case I tend to agree, because implementing other people's
>>> solutions can take the fun out of programming. But reading them never
>>> hurts. And when you agree to a certain approach you can even decide to
>>> follow it yourself. It is all up to you, the programmer.)
>>>
>>
>> Any rules TNP doesn't bother to understand are "arbitrary" in his mind.
>> He doesn't even like having to follow PHP syntax rules - as he has also
>> said in the past.
>>
>> But I disagree that PHP 5's implementation of OO is decent. I think it's
>> half-assed at best. Truly written by people who have no understanding of
>> OO. But then that can be said of a lot of PHP.
>>
>
> Jerry,
>
> What are your main objections to the PHP5's OO approach?
>
> For myself: I must say I love its simplicity.
> (Simplicity is a Good Thing in my opinion.)
>
>
>
> <snip>
>
>>> But even then, OO often won't hurt too much either.
>>> You can simply use your procedural logic in OO too.
>>> I worked like that in Java when I started learning the language, until I
>>> discovered how idiotic I was. All part of the learning curve. :-)
>>>
>>
>> I agree - I've seen some things which work better using a procedural
>> approach. But I've also found the more complicated something gets, the
>> more appropriate an OO approach becomes.
>>
>
> Exactly. :-)
>
> <snip>
>
>>>>
>>>> (and almost all of the problems to which PHP is the natural language of
>>>> choice do not benefit from OOP. If a web site is the application each
>>>> php 'page' is an object in its own right..anyway.
>>>
>>> True for a simple plain webpage, but when you have something more
>>> complex OO can certainly help.
>>> Most (all?) modern MVC software are at least partly OO, simply because
>>> it makes things easier to organize.
>>>
>>
>> No, a page is not an object. A page is closer to a transactional
>> application. For instance, the page cannot be reused in another page
>> without modifications. Objects can.
>>
>
> No, of course a page is not an object in the OO meaning.
> I was referring to using OO to help building the page.
>
It is an object in that its self contained .. and doesn't extend into
other pages. Its data is self contained.
> I wonder: one might defend that storing serialized objects in a session
> is object persistence, and that a page is hence also part of it because
> it is coupled via sess_id to that object.
> Nah.. too farfetched.
> (And I never store objects in a session anymore: not worth the trouble
> in my opinion.)
>
No. Its simpler to generate your own cookie, use that to id the
transaction and store everything else elsewhere. Typically a database.
> <snip>
>
>>
>> I can code Intel processors - I started back in '82 when the typical PC
>> had 64K or 128K of RAM (and slow). We needed to do some stuff in 808x
>> assembler. I still do a little as a hobby (mainly to keep up with it),
>> but I don't go down to the OS level.
>>
>
> Nice!
> And I feel like a relic now with my 6502 hands-on experience. ;-)
>
I've coded 8080, z80, 8088, 8086 and 6809.. after that it was mostly
done in C...
C is just qa faster way to write quality assembler.
Once you step into the arena of garbage collection, invisible memory
manipulation and start hiding the actual realities of the machine from
the language you end up with the possibility of really bad bloated code
and seriously crap performance.
I.e. basically what the modern user application is characterised by.
> 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: out of sheer curiosity... [message #177439 is a reply to message #177436] |
Thu, 29 March 2012 20:11 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 3/29/2012 10:21 AM, Erwin Moller wrote:
> On 3/29/2012 3:39 PM, Jerry Stuckle wrote:
>> On 3/29/2012 8:33 AM, Erwin Moller wrote:
>>> On 3/29/2012 12:46 PM, The Natural Philosopher wrote:
>
> <snip>
>
>>>> Its just another way of doing things and I let my understanding of the
>>>> problem guide me, not a set of arbitrary rules.
>>>
>>> As it should!
>>>
>>> But what 'rules' are you referring to?
>>>
>>> PHP's OO is pretty straightforward.
>>> I think they did a decent job implementing OO.(php 5 that is)
>>>
>>> Creating smart classes is up to the programmer.
>>> I am not aware of any extra 'rules'.
>>>
>>> Are you maybe referring to all kinds of design patterns scattered around
>>> the web?
>>> (In which case I tend to agree, because implementing other people's
>>> solutions can take the fun out of programming. But reading them never
>>> hurts. And when you agree to a certain approach you can even decide to
>>> follow it yourself. It is all up to you, the programmer.)
>>>
>>
>> Any rules TNP doesn't bother to understand are "arbitrary" in his mind.
>> He doesn't even like having to follow PHP syntax rules - as he has also
>> said in the past.
>>
>> But I disagree that PHP 5's implementation of OO is decent. I think it's
>> half-assed at best. Truly written by people who have no understanding of
>> OO. But then that can be said of a lot of PHP.
>>
>
> Jerry,
>
> What are your main objections to the PHP5's OO approach?
>
> For myself: I must say I love its simplicity.
> (Simplicity is a Good Thing in my opinion.)
>
>
Well, to start with, the lack of function overloading. It is quite a
good feature to be able to overload functions - especially constructors.
And because of that, you have to run through all kinds of hoops when
doing things like storing an object in the $_SESSION.
Even then it doesn't work. When you store an object in the $_SESSION,
the object's destructor is called at the end of the script, but on the
next script the constructor is never called. A direct violation of OO
principles.
Inheritance is also screwed up. You should never have to call the
constructor of the parent object from your child's constructor. It
should be automatic.
Polymorphism works half-assed, but again you need to run through hoops.
For instance, base class has static method "foo". It also calls
static method "bar". Derived class also has method "bar". If you call
derived::foo(), you will end up calling Base::bar() instead of
Derived::bar(). They fixed this in 5.3 by forcing (yet another!) use of
the keyword static - instead of making the code work transparently.
There are all kinds of similar things in PHP. But that's not really
that surprising to me.
>
> <snip>
>
>>>>
>>>> (and almost all of the problems to which PHP is the natural language of
>>>> choice do not benefit from OOP. If a web site is the application each
>>>> php 'page' is an object in its own right..anyway.
>>>
>>> True for a simple plain webpage, but when you have something more
>>> complex OO can certainly help.
>>> Most (all?) modern MVC software are at least partly OO, simply because
>>> it makes things easier to organize.
>>>
>>
>> No, a page is not an object. A page is closer to a transactional
>> application. For instance, the page cannot be reused in another page
>> without modifications. Objects can.
>>
>
> No, of course a page is not an object in the OO meaning.
> I was referring to using OO to help building the page.
>
> I wonder: one might defend that storing serialized objects in a session
> is object persistence, and that a page is hence also part of it because
> it is coupled via sess_id to that object.
> Nah.. too farfetched.
> (And I never store objects in a session anymore: not worth the trouble
> in my opinion.)
>
> <snip>
>
Storing the object in the $_SESSION is object persistence. But that
doesn't make the page itself an object in the OO sense, any more than MS
Word is an object because you can store a document on disk for later
retrieval.
And I agree about storing objects in the session (see above). But that
also means even more hoops you have to run through to store and retrieve
your object.
>>
>> I can code Intel processors - I started back in '82 when the typical PC
>> had 64K or 128K of RAM (and slow). We needed to do some stuff in 808x
>> assembler. I still do a little as a hobby (mainly to keep up with it),
>> but I don't go down to the OS level.
>>
>
> Nice!
> And I feel like a relic now with my 6502 hands-on experience. ;-)
>
> Regards,
> Erwin Moller
>
I should add, I never did any 6502. I did some 6800 back around 1980 or
so, and have done lots of IBM Mainframe assembler (and even a fair
amount of machine code - their instruction set makes it relatively
easy). But never had the opportunity to do anything on the 6502.
I have mixed feelings about assembler. It's nice when you need the
speed and/or memory, but those aren't so much of a problem nowadays.
But it really is a bear to try to do anything more than adding a couple
of registers together :)
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: out of sheer curiosity... [message #177440 is a reply to message #177439] |
Thu, 29 March 2012 21:01 |
Tim Streater
Messages: 328
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
In article <jl2fl0$v97$1(at)dont-email(dot)me>,
Jerry Stuckle <jstucklex(at)attglobal(dot)net> wrote:
> On 29/3/2012 10:21 AM, Erwin Moller wrote:
>> What are your main objections to the PHP5's OO approach?
>>
>> For myself: I must say I love its simplicity.
>> (Simplicity is a Good Thing in my opinion.)
> Well, to start with, the lack of function overloading. It is quite a
> good feature to be able to overload functions - especially constructors.
> And because of that, you have to run through all kinds of hoops when
> doing things like storing an object in the $_SESSION.
[snip other reasons]
You brought any of this up on the PHP mailing lists?
--
Tim
"That excessive bail ought not to be required, nor excessive fines imposed,
nor cruel and unusual punishments inflicted" -- Bill of Rights 1689
|
|
|
|
| Re: out of sheer curiosity... [message #177441 is a reply to message #177438] |
Thu, 29 March 2012 21:07 |
Tim Streater
Messages: 328
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
In article <jl250b$lkq$1(at)news(dot)albasani(dot)net>,
The Natural Philosopher <tnp(at)invalid(dot)invalid> wrote:
> Erwin Moller wrote:
>> Nice!
>> And I feel like a relic now with my 6502 hands-on experience. ;-)
>>
> I've coded 8080, z80, 8088, 8086 and 6809.. after that it was mostly
> done in C...
I found I could do a decent job on the 7090 and Sigma7, and a very
decent job on the 68000. 6502/Z80/8080 were simple but hard to do very
much with. I avoided the x86. The IBM/360 definitely had the worst I've
ever seen. PDP-11 and VAX were quite good.
> C is just a faster way to write quality assembler.
While this is true, there are times when machine code is unavoidable.
--
Tim
"That excessive bail ought not to be required, nor excessive fines imposed,
nor cruel and unusual punishments inflicted" -- Bill of Rights 1689
|
|
|
|
| Re: out of sheer curiosity... [message #177442 is a reply to message #177441] |
Thu, 29 March 2012 21:43 |
M. Strobel
Messages: 386
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
Am 29.03.2012 23:07, schrieb Tim Streater:
> In article <jl250b$lkq$1(at)news(dot)albasani(dot)net>,
> The Natural Philosopher <tnp(at)invalid(dot)invalid> wrote:
>
>> Erwin Moller wrote:
>
>>> Nice!
>>> And I feel like a relic now with my 6502 hands-on experience. ;-)
>>> I've coded 8080, z80, 8088, 8086 and 6809.. after that it was mostly done in C...
>
> I found I could do a decent job on the 7090 and Sigma7, and a very decent job on the
> 68000. 6502/Z80/8080 were simple but hard to do very much with. I avoided the x86.
> The IBM/360 definitely had the worst I've ever seen. PDP-11 and VAX were quite good.
I did a lot in /370 assembler, and it really has a different paradigma: no stack, but
15 registers which was a lot at that time.
No problem, I wrote a FORTH on it.
Which brings us back to the subject: make best use of what your environment has to
offer. The environment today has more to offer than assembler.
/Str.
|
|
|
|
| Re: out of sheer curiosity... [message #177443 is a reply to message #177440] |
Thu, 29 March 2012 23:29 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 3/29/2012 5:01 PM, Tim Streater wrote:
> In article <jl2fl0$v97$1(at)dont-email(dot)me>,
> Jerry Stuckle <jstucklex(at)attglobal(dot)net> wrote:
>
>> On 29/3/2012 10:21 AM, Erwin Moller wrote:
>
>>> What are your main objections to the PHP5's OO approach?
>>>
>>> For myself: I must say I love its simplicity.
>>> (Simplicity is a Good Thing in my opinion.)
>
>> Well, to start with, the lack of function overloading. It is quite a
>> good feature to be able to overload functions - especially
>> constructors. And because of that, you have to run through all kinds
>> of hoops when doing things like storing an object in the $_SESSION.
>
> [snip other reasons]
>
> You brought any of this up on the PHP mailing lists?
>
It's been brought up so many times it isn't even funny, and some of it
in the bugs list.
I do not have a lot of respect for those in charge of PHP. Just because
they can program an interpreter does not mean they can design a
language. And PHP is proof of that.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: out of sheer curiosity... [message #177444 is a reply to message #177441] |
Fri, 30 March 2012 03:52 |
The Natural Philosoph
Messages: 993
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
Tim Streater wrote:
> In article <jl250b$lkq$1(at)news(dot)albasani(dot)net>,
> The Natural Philosopher <tnp(at)invalid(dot)invalid> wrote:
>
>> Erwin Moller wrote:
>
>>> Nice!
>>> And I feel like a relic now with my 6502 hands-on experience. ;-)
>>> I've coded 8080, z80, 8088, 8086 and 6809.. after that it was mostly
>> done in C...
>
> I found I could do a decent job on the 7090 and Sigma7, and a very
> decent job on the 68000. 6502/Z80/8080 were simple but hard to do very
> much with. I avoided the x86. The IBM/360 definitely had the worst I've
> ever seen. PDP-11 and VAX were quite good.
>
>> C is just a faster way to write quality assembler.
>
> While this is true, there are times when machine code is unavoidable.
>
of course. mostly when actually zapping hardware. Unless your C library
has specific hardware access stuff. And interrupt routine hooks.
--
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: out of sheer curiosity... [message #177539 is a reply to message #177439] |
Sun, 08 April 2012 20:50 |
M. Strobel
Messages: 386
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
Am 29.03.2012 22:11, schrieb Jerry Stuckle:
> On 3/29/2012 10:21 AM, Erwin Moller wrote:
>> On 3/29/2012 3:39 PM, Jerry Stuckle wrote:
>>> On 3/29/2012 8:33 AM, Erwin Moller wrote:
>>>> On 3/29/2012 12:46 PM, The Natural Philosopher wrote:
>>
>> <snip>
>>
>>>> > Its just another way of doing things and I let my understanding of the
>>>> > problem guide me, not a set of arbitrary rules.
>>>>
>>>> As it should!
>>>>
>>>> But what 'rules' are you referring to?
>>>>
>>>> PHP's OO is pretty straightforward.
>>>> I think they did a decent job implementing OO.(php 5 that is)
>>>>
>>>> Creating smart classes is up to the programmer.
>>>> I am not aware of any extra 'rules'.
>>>>
>>>> Are you maybe referring to all kinds of design patterns scattered around
>>>> the web?
>>>> (In which case I tend to agree, because implementing other people's
>>>> solutions can take the fun out of programming. But reading them never
>>>> hurts. And when you agree to a certain approach you can even decide to
>>>> follow it yourself. It is all up to you, the programmer.)
>>>>
>>>
>>> Any rules TNP doesn't bother to understand are "arbitrary" in his mind.
>>> He doesn't even like having to follow PHP syntax rules - as he has also
>>> said in the past.
>>>
>>> But I disagree that PHP 5's implementation of OO is decent. I think it's
>>> half-assed at best. Truly written by people who have no understanding of
>>> OO. But then that can be said of a lot of PHP.
>>>
>>
>> Jerry,
>>
>> What are your main objections to the PHP5's OO approach?
>>
>> For myself: I must say I love its simplicity.
>> (Simplicity is a Good Thing in my opinion.)
>>
>>
>
> Well, to start with, the lack of function overloading. It is quite a good feature to
> be able to overload functions - especially constructors. And because of that, you
> have to run through all kinds of hoops when doing things like storing an object in
> the $_SESSION.
>
> Even then it doesn't work. When you store an object in the $_SESSION, the object's
> destructor is called at the end of the script, but on the next script the constructor
> is never called. A direct violation of OO principles.
Works fine here. Test script:
#!/usr/local/bin/php
<?php
class C1 {
public $var1 = 'M.';
public $var2 = 'Strobel';
function __construct() {
echo "\t--> call ". __METHOD__.PHP_EOL;
}
function __destruct() {
echo "\t--> call ". __METHOD__.PHP_EOL;
}
function __sleep() {
echo "\t--> call ". __METHOD__.PHP_EOL;
return array('var1','var2');
}
function __wakeup() {
echo "\t--> call ". __METHOD__.PHP_EOL;
}
} // end class C1
echo "----- creating class\n";
$c = new C1;
echo "----- serializing class\n";
$ser = serialize($c);
echo "----- deserializing class\n";
$cc = unserialize($ser);
echo "----- deleting first class\n";
unset($c);
echo "----- deleting unserialized class\n";
unset($cc);
exit(0);
#-----------------------
Result:
strobel@s114-intel:~/projekte/PHP> ./magicmethods.php
----- creating class
--> call C1::__construct
----- serializing class
--> call C1::__sleep
----- deserializing class
--> call C1::__wakeup
----- deleting first class
--> call C1::__destruct
----- deleting unserialized class
--> call C1::__destruct
What exactly did you criticize?
/Str.
|
|
|
|
| Re: out of sheer curiosity... [message #177540 is a reply to message #177539] |
Sun, 08 April 2012 21:15 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 4/8/2012 4:50 PM, M. Strobel wrote:
> Am 29.03.2012 22:11, schrieb Jerry Stuckle:
>> On 3/29/2012 10:21 AM, Erwin Moller wrote:
>>> On 3/29/2012 3:39 PM, Jerry Stuckle wrote:
>>>> On 3/29/2012 8:33 AM, Erwin Moller wrote:
>>>> > On 3/29/2012 12:46 PM, The Natural Philosopher wrote:
>>>
>>> <snip>
>>>
>>>> >> Its just another way of doing things and I let my understanding of the
>>>> >> problem guide me, not a set of arbitrary rules.
>>>> >
>>>> > As it should!
>>>> >
>>>> > But what 'rules' are you referring to?
>>>> >
>>>> > PHP's OO is pretty straightforward.
>>>> > I think they did a decent job implementing OO.(php 5 that is)
>>>> >
>>>> > Creating smart classes is up to the programmer.
>>>> > I am not aware of any extra 'rules'.
>>>> >
>>>> > Are you maybe referring to all kinds of design patterns scattered around
>>>> > the web?
>>>> > (In which case I tend to agree, because implementing other people's
>>>> > solutions can take the fun out of programming. But reading them never
>>>> > hurts. And when you agree to a certain approach you can even decide to
>>>> > follow it yourself. It is all up to you, the programmer.)
>>>> >
>>>>
>>>> Any rules TNP doesn't bother to understand are "arbitrary" in his mind.
>>>> He doesn't even like having to follow PHP syntax rules - as he has also
>>>> said in the past.
>>>>
>>>> But I disagree that PHP 5's implementation of OO is decent. I think it's
>>>> half-assed at best. Truly written by people who have no understanding of
>>>> OO. But then that can be said of a lot of PHP.
>>>>
>>>
>>> Jerry,
>>>
>>> What are your main objections to the PHP5's OO approach?
>>>
>>> For myself: I must say I love its simplicity.
>>> (Simplicity is a Good Thing in my opinion.)
>>>
>>>
>>
>> Well, to start with, the lack of function overloading. It is quite a good feature to
>> be able to overload functions - especially constructors. And because of that, you
>> have to run through all kinds of hoops when doing things like storing an object in
>> the $_SESSION.
>>
>> Even then it doesn't work. When you store an object in the $_SESSION, the object's
>> destructor is called at the end of the script, but on the next script the constructor
>> is never called. A direct violation of OO principles.
>
> Works fine here. Test script:
> #!/usr/local/bin/php
> <?php
>
> class C1 {
> public $var1 = 'M.';
> public $var2 = 'Strobel';
> function __construct() {
> echo "\t--> call ". __METHOD__.PHP_EOL;
> }
> function __destruct() {
> echo "\t--> call ". __METHOD__.PHP_EOL;
> }
> function __sleep() {
> echo "\t--> call ". __METHOD__.PHP_EOL;
> return array('var1','var2');
> }
> function __wakeup() {
> echo "\t--> call ". __METHOD__.PHP_EOL;
> }
> } // end class C1
>
> echo "----- creating class\n";
> $c = new C1;
> echo "----- serializing class\n";
> $ser = serialize($c);
> echo "----- deserializing class\n";
> $cc = unserialize($ser);
> echo "----- deleting first class\n";
> unset($c);
> echo "----- deleting unserialized class\n";
> unset($cc);
> exit(0);
> #-----------------------
>
> Result:
> strobel@s114-intel:~/projekte/PHP> ./magicmethods.php
> ----- creating class
> --> call C1::__construct
> ----- serializing class
> --> call C1::__sleep
> ----- deserializing class
> --> call C1::__wakeup
> ----- deleting first class
> --> call C1::__destruct
> ----- deleting unserialized class
> --> call C1::__destruct
>
> What exactly did you criticize?
>
> /Str.
Look at it again. You have two destructor calls but only one
constructor call. A direct violation of OO principles.
And BTW - I said nothing about serializing.
You really do need to learn to read.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: out of sheer curiosity... [message #177544 is a reply to message #177540] |
Sun, 08 April 2012 22:39 |
M. Strobel
Messages: 386
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
Am 08.04.2012 23:15, schrieb Jerry Stuckle:
> On 4/8/2012 4:50 PM, M. Strobel wrote:
>> Am 29.03.2012 22:11, schrieb Jerry Stuckle:
>>> On 3/29/2012 10:21 AM, Erwin Moller wrote:
>>>> On 3/29/2012 3:39 PM, Jerry Stuckle wrote:
>>>> > On 3/29/2012 8:33 AM, Erwin Moller wrote:
>>>> >> On 3/29/2012 12:46 PM, The Natural Philosopher wrote:
>>>>
>>>> <snip>
>>>>
>>>> >>> Its just another way of doing things and I let my understanding of the
>>>> >>> problem guide me, not a set of arbitrary rules.
>>>> >>
>>>> >> As it should!
>>>> >>
>>>> >> But what 'rules' are you referring to?
>>>> >>
>>>> >> PHP's OO is pretty straightforward.
>>>> >> I think they did a decent job implementing OO.(php 5 that is)
>>>> >>
>>>> >> Creating smart classes is up to the programmer.
>>>> >> I am not aware of any extra 'rules'.
>>>> >>
>>>> >> Are you maybe referring to all kinds of design patterns scattered around
>>>> >> the web?
>>>> >> (In which case I tend to agree, because implementing other people's
>>>> >> solutions can take the fun out of programming. But reading them never
>>>> >> hurts. And when you agree to a certain approach you can even decide to
>>>> >> follow it yourself. It is all up to you, the programmer.)
>>>> >>
>>>> >
>>>> > Any rules TNP doesn't bother to understand are "arbitrary" in his mind.
>>>> > He doesn't even like having to follow PHP syntax rules - as he has also
>>>> > said in the past.
>>>> >
>>>> > But I disagree that PHP 5's implementation of OO is decent. I think it's
>>>> > half-assed at best. Truly written by people who have no understanding of
>>>> > OO. But then that can be said of a lot of PHP.
>>>> >
>>>>
>>>> Jerry,
>>>>
>>>> What are your main objections to the PHP5's OO approach?
>>>>
>>>> For myself: I must say I love its simplicity.
>>>> (Simplicity is a Good Thing in my opinion.)
>>>>
>>>>
>>>
>>> Well, to start with, the lack of function overloading. It is quite a good feature to
>>> be able to overload functions - especially constructors. And because of that, you
>>> have to run through all kinds of hoops when doing things like storing an object in
>>> the $_SESSION.
>>>
>>> Even then it doesn't work. When you store an object in the $_SESSION, the object's
>>> destructor is called at the end of the script, but on the next script the constructor
>>> is never called. A direct violation of OO principles.
>>
>> Works fine here. Test script:
>> #!/usr/local/bin/php
>> <?php
>>
>> class C1 {
>> public $var1 = 'M.';
>> public $var2 = 'Strobel';
>> function __construct() {
>> echo "\t--> call ". __METHOD__.PHP_EOL;
>> }
>> function __destruct() {
>> echo "\t--> call ". __METHOD__.PHP_EOL;
>> }
>> function __sleep() {
>> echo "\t--> call ". __METHOD__.PHP_EOL;
>> return array('var1','var2');
>> }
>> function __wakeup() {
>> echo "\t--> call ". __METHOD__.PHP_EOL;
>> }
>> } // end class C1
>>
>> echo "----- creating class\n";
>> $c = new C1;
>> echo "----- serializing class\n";
>> $ser = serialize($c);
>> echo "----- deserializing class\n";
>> $cc = unserialize($ser);
>> echo "----- deleting first class\n";
>> unset($c);
>> echo "----- deleting unserialized class\n";
>> unset($cc);
>> exit(0);
>> #-----------------------
>>
>> Result:
>> strobel@s114-intel:~/projekte/PHP> ./magicmethods.php
>> ----- creating class
>> --> call C1::__construct
>> ----- serializing class
>> --> call C1::__sleep
>> ----- deserializing class
>> --> call C1::__wakeup
>> ----- deleting first class
>> --> call C1::__destruct
>> ----- deleting unserialized class
>> --> call C1::__destruct
>>
>> What exactly did you criticize?
>>
>> /Str.
>
> Look at it again. You have two destructor calls but only one constructor call. A
> direct violation of OO principles.
>
> And BTW - I said nothing about serializing.
>
> You really do need to learn to read.
>
No evasions, get to the point. I have one explicit constructor, and one wakeup which
is a constructor.
What did you talk about if not about serializing?
/Str.
|
|
|
|
| Re: out of sheer curiosity... [message #177545 is a reply to message #177544] |
Sun, 08 April 2012 23:59 |
The Natural Philosoph
Messages: 993
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
M. Strobel wrote:
> Am 08.04.2012 23:15, schrieb Jerry Stuckle:
>> On 4/8/2012 4:50 PM, M. Strobel wrote:
>>> Am 29.03.2012 22:11, schrieb Jerry Stuckle:
>>>> On 3/29/2012 10:21 AM, Erwin Moller wrote:
>>>> > On 3/29/2012 3:39 PM, Jerry Stuckle wrote:
>>>> >> On 3/29/2012 8:33 AM, Erwin Moller wrote:
>>>> >>> On 3/29/2012 12:46 PM, The Natural Philosopher wrote:
>>>> > <snip>
>>>> >
>>>> >>>> Its just another way of doing things and I let my understanding of the
>>>> >>>> problem guide me, not a set of arbitrary rules.
>>>> >>> As it should!
>>>> >>>
>>>> >>> But what 'rules' are you referring to?
>>>> >>>
>>>> >>> PHP's OO is pretty straightforward.
>>>> >>> I think they did a decent job implementing OO.(php 5 that is)
>>>> >>>
>>>> >>> Creating smart classes is up to the programmer.
>>>> >>> I am not aware of any extra 'rules'.
>>>> >>>
>>>> >>> Are you maybe referring to all kinds of design patterns scattered around
>>>> >>> the web?
>>>> >>> (In which case I tend to agree, because implementing other people's
>>>> >>> solutions can take the fun out of programming. But reading them never
>>>> >>> hurts. And when you agree to a certain approach you can even decide to
>>>> >>> follow it yourself. It is all up to you, the programmer.)
>>>> >>>
>>>> >> Any rules TNP doesn't bother to understand are "arbitrary" in his mind.
>>>> >> He doesn't even like having to follow PHP syntax rules - as he has also
>>>> >> said in the past.
>>>> >>
>>>> >> But I disagree that PHP 5's implementation of OO is decent. I think it's
>>>> >> half-assed at best. Truly written by people who have no understanding of
>>>> >> OO. But then that can be said of a lot of PHP.
>>>> >>
>>>> > Jerry,
>>>> >
>>>> > What are your main objections to the PHP5's OO approach?
>>>> >
>>>> > For myself: I must say I love its simplicity.
>>>> > (Simplicity is a Good Thing in my opinion.)
>>>> >
>>>> >
>>>> Well, to start with, the lack of function overloading. It is quite a good feature to
>>>> be able to overload functions - especially constructors. And because of that, you
>>>> have to run through all kinds of hoops when doing things like storing an object in
>>>> the $_SESSION.
>>>>
>>>> Even then it doesn't work. When you store an object in the $_SESSION, the object's
>>>> destructor is called at the end of the script, but on the next script the constructor
>>>> is never called. A direct violation of OO principles.
>>> Works fine here. Test script:
>>> #!/usr/local/bin/php
>>> <?php
>>>
>>> class C1 {
>>> public $var1 = 'M.';
>>> public $var2 = 'Strobel';
>>> function __construct() {
>>> echo "\t--> call ". __METHOD__.PHP_EOL;
>>> }
>>> function __destruct() {
>>> echo "\t--> call ". __METHOD__.PHP_EOL;
>>> }
>>> function __sleep() {
>>> echo "\t--> call ". __METHOD__.PHP_EOL;
>>> return array('var1','var2');
>>> }
>>> function __wakeup() {
>>> echo "\t--> call ". __METHOD__.PHP_EOL;
>>> }
>>> } // end class C1
>>>
>>> echo "----- creating class\n";
>>> $c = new C1;
>>> echo "----- serializing class\n";
>>> $ser = serialize($c);
>>> echo "----- deserializing class\n";
>>> $cc = unserialize($ser);
>>> echo "----- deleting first class\n";
>>> unset($c);
>>> echo "----- deleting unserialized class\n";
>>> unset($cc);
>>> exit(0);
>>> #-----------------------
>>>
>>> Result:
>>> strobel@s114-intel:~/projekte/PHP> ./magicmethods.php
>>> ----- creating class
>>> --> call C1::__construct
>>> ----- serializing class
>>> --> call C1::__sleep
>>> ----- deserializing class
>>> --> call C1::__wakeup
>>> ----- deleting first class
>>> --> call C1::__destruct
>>> ----- deleting unserialized class
>>> --> call C1::__destruct
>>>
>>> What exactly did you criticize?
>>>
>>> /Str.
>> Look at it again. You have two destructor calls but only one constructor call. A
>> direct violation of OO principles.
>>
>> And BTW - I said nothing about serializing.
>>
>> You really do need to learn to read.
>>
>
> No evasions, get to the point. I have one explicit constructor, and one wakeup which
> is a constructor.
>
> What did you talk about if not about serializing?
>
> /Str.
c'mon. Jerry just cut and pasted something he read somewhere.
Its not as if he understood what he was posting. Go easy on the poor old
chap.
--
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: out of sheer curiosity... [message #177546 is a reply to message #177544] |
Mon, 09 April 2012 00:24 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 4/8/2012 6:39 PM, M. Strobel wrote:
> Am 08.04.2012 23:15, schrieb Jerry Stuckle:
>> On 4/8/2012 4:50 PM, M. Strobel wrote:
>>> Am 29.03.2012 22:11, schrieb Jerry Stuckle:
>>>> On 3/29/2012 10:21 AM, Erwin Moller wrote:
>>>> > On 3/29/2012 3:39 PM, Jerry Stuckle wrote:
>>>> >> On 3/29/2012 8:33 AM, Erwin Moller wrote:
>>>> >>> On 3/29/2012 12:46 PM, The Natural Philosopher wrote:
>>>> >
>>>> > <snip>
>>>> >
>>>> >>>> Its just another way of doing things and I let my understanding of the
>>>> >>>> problem guide me, not a set of arbitrary rules.
>>>> >>>
>>>> >>> As it should!
>>>> >>>
>>>> >>> But what 'rules' are you referring to?
>>>> >>>
>>>> >>> PHP's OO is pretty straightforward.
>>>> >>> I think they did a decent job implementing OO.(php 5 that is)
>>>> >>>
>>>> >>> Creating smart classes is up to the programmer.
>>>> >>> I am not aware of any extra 'rules'.
>>>> >>>
>>>> >>> Are you maybe referring to all kinds of design patterns scattered around
>>>> >>> the web?
>>>> >>> (In which case I tend to agree, because implementing other people's
>>>> >>> solutions can take the fun out of programming. But reading them never
>>>> >>> hurts. And when you agree to a certain approach you can even decide to
>>>> >>> follow it yourself. It is all up to you, the programmer.)
>>>> >>>
>>>> >>
>>>> >> Any rules TNP doesn't bother to understand are "arbitrary" in his mind.
>>>> >> He doesn't even like having to follow PHP syntax rules - as he has also
>>>> >> said in the past.
>>>> >>
>>>> >> But I disagree that PHP 5's implementation of OO is decent. I think it's
>>>> >> half-assed at best. Truly written by people who have no understanding of
>>>> >> OO. But then that can be said of a lot of PHP.
>>>> >>
>>>> >
>>>> > Jerry,
>>>> >
>>>> > What are your main objections to the PHP5's OO approach?
>>>> >
>>>> > For myself: I must say I love its simplicity.
>>>> > (Simplicity is a Good Thing in my opinion.)
>>>> >
>>>> >
>>>>
>>>> Well, to start with, the lack of function overloading. It is quite a good feature to
>>>> be able to overload functions - especially constructors. And because of that, you
>>>> have to run through all kinds of hoops when doing things like storing an object in
>>>> the $_SESSION.
>>>>
>>>> Even then it doesn't work. When you store an object in the $_SESSION, the object's
>>>> destructor is called at the end of the script, but on the next script the constructor
>>>> is never called. A direct violation of OO principles.
>>>
>>> Works fine here. Test script:
>>> #!/usr/local/bin/php
>>> <?php
>>>
>>> class C1 {
>>> public $var1 = 'M.';
>>> public $var2 = 'Strobel';
>>> function __construct() {
>>> echo "\t--> call ". __METHOD__.PHP_EOL;
>>> }
>>> function __destruct() {
>>> echo "\t--> call ". __METHOD__.PHP_EOL;
>>> }
>>> function __sleep() {
>>> echo "\t--> call ". __METHOD__.PHP_EOL;
>>> return array('var1','var2');
>>> }
>>> function __wakeup() {
>>> echo "\t--> call ". __METHOD__.PHP_EOL;
>>> }
>>> } // end class C1
>>>
>>> echo "----- creating class\n";
>>> $c = new C1;
>>> echo "----- serializing class\n";
>>> $ser = serialize($c);
>>> echo "----- deserializing class\n";
>>> $cc = unserialize($ser);
>>> echo "----- deleting first class\n";
>>> unset($c);
>>> echo "----- deleting unserialized class\n";
>>> unset($cc);
>>> exit(0);
>>> #-----------------------
>>>
>>> Result:
>>> strobel@s114-intel:~/projekte/PHP> ./magicmethods.php
>>> ----- creating class
>>> --> call C1::__construct
>>> ----- serializing class
>>> --> call C1::__sleep
>>> ----- deserializing class
>>> --> call C1::__wakeup
>>> ----- deleting first class
>>> --> call C1::__destruct
>>> ----- deleting unserialized class
>>> --> call C1::__destruct
>>>
>>> What exactly did you criticize?
>>>
>>> /Str.
>>
>> Look at it again. You have two destructor calls but only one constructor call. A
>> direct violation of OO principles.
>>
>> And BTW - I said nothing about serializing.
>>
>> You really do need to learn to read.
>>
>
> No evasions, get to the point. I have one explicit constructor, and one wakeup which
> is a constructor.
>
> What did you talk about if not about serializing?
>
> /Str.
I know a one-to-one correspondence is very difficult for someone of your
(lack of) intellect to understand, but I'll try again anyway.
You have these calls:
--> call C1::__construct
That's ONE call to a constructor.
--> call C1::__destruct
--> call C1::__destruct
That's TWO calls to destructors. IOW, an object was constructed without
calling a constructor. This is a direct violation of OO principals (all
objects must have exactly one constructor call and one destructor call).
And ONE does not equal TWO. wakeup() is not a constructor, any more
than sleep() is a destructor (and if sleep() were a destructor, then you
would see a call to sleep() and a call to the destructor).
And I was referring to storing in a session, not serializing the data, i.e.
$_SESSION['stupid'] = $idiot;
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: out of sheer curiosity... [message #177547 is a reply to message #177545] |
Mon, 09 April 2012 00:28 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 4/8/2012 7:59 PM, The Natural Philosopher wrote:
> M. Strobel wrote:
>> Am 08.04.2012 23:15, schrieb Jerry Stuckle:
>>> On 4/8/2012 4:50 PM, M. Strobel wrote:
>>>> Am 29.03.2012 22:11, schrieb Jerry Stuckle:
>>>> > On 3/29/2012 10:21 AM, Erwin Moller wrote:
>>>> >> On 3/29/2012 3:39 PM, Jerry Stuckle wrote:
>>>> >>> On 3/29/2012 8:33 AM, Erwin Moller wrote:
>>>> >>>> On 3/29/2012 12:46 PM, The Natural Philosopher wrote:
>>>> >> <snip>
>>>> >>
>>>> >>>>> Its just another way of doing things and I let my understanding
>>>> >>>>> of the
>>>> >>>>> problem guide me, not a set of arbitrary rules.
>>>> >>>> As it should!
>>>> >>>>
>>>> >>>> But what 'rules' are you referring to?
>>>> >>>>
>>>> >>>> PHP's OO is pretty straightforward.
>>>> >>>> I think they did a decent job implementing OO.(php 5 that is)
>>>> >>>>
>>>> >>>> Creating smart classes is up to the programmer.
>>>> >>>> I am not aware of any extra 'rules'.
>>>> >>>>
>>>> >>>> Are you maybe referring to all kinds of design patterns
>>>> >>>> scattered around
>>>> >>>> the web?
>>>> >>>> (In which case I tend to agree, because implementing other people's
>>>> >>>> solutions can take the fun out of programming. But reading them
>>>> >>>> never
>>>> >>>> hurts. And when you agree to a certain approach you can even
>>>> >>>> decide to
>>>> >>>> follow it yourself. It is all up to you, the programmer.)
>>>> >>>>
>>>> >>> Any rules TNP doesn't bother to understand are "arbitrary" in his
>>>> >>> mind.
>>>> >>> He doesn't even like having to follow PHP syntax rules - as he
>>>> >>> has also
>>>> >>> said in the past.
>>>> >>>
>>>> >>> But I disagree that PHP 5's implementation of OO is decent. I
>>>> >>> think it's
>>>> >>> half-assed at best. Truly written by people who have no
>>>> >>> understanding of
>>>> >>> OO. But then that can be said of a lot of PHP.
>>>> >>>
>>>> >> Jerry,
>>>> >>
>>>> >> What are your main objections to the PHP5's OO approach?
>>>> >>
>>>> >> For myself: I must say I love its simplicity.
>>>> >> (Simplicity is a Good Thing in my opinion.)
>>>> >>
>>>> >>
>>>> > Well, to start with, the lack of function overloading. It is quite
>>>> > a good feature to
>>>> > be able to overload functions - especially constructors. And
>>>> > because of that, you
>>>> > have to run through all kinds of hoops when doing things like
>>>> > storing an object in
>>>> > the $_SESSION.
>>>> >
>>>> > Even then it doesn't work. When you store an object in the
>>>> > $_SESSION, the object's
>>>> > destructor is called at the end of the script, but on the next
>>>> > script the constructor
>>>> > is never called. A direct violation of OO principles.
>>>> Works fine here. Test script:
>>>> #!/usr/local/bin/php
>>>> <?php
>>>>
>>>> class C1 {
>>>> public $var1 = 'M.';
>>>> public $var2 = 'Strobel';
>>>> function __construct() {
>>>> echo "\t--> call ". __METHOD__.PHP_EOL;
>>>> }
>>>> function __destruct() {
>>>> echo "\t--> call ". __METHOD__.PHP_EOL;
>>>> }
>>>> function __sleep() {
>>>> echo "\t--> call ". __METHOD__.PHP_EOL;
>>>> return array('var1','var2');
>>>> }
>>>> function __wakeup() {
>>>> echo "\t--> call ". __METHOD__.PHP_EOL;
>>>> }
>>>> } // end class C1
>>>>
>>>> echo "----- creating class\n";
>>>> $c = new C1;
>>>> echo "----- serializing class\n";
>>>> $ser = serialize($c);
>>>> echo "----- deserializing class\n";
>>>> $cc = unserialize($ser);
>>>> echo "----- deleting first class\n";
>>>> unset($c);
>>>> echo "----- deleting unserialized class\n";
>>>> unset($cc);
>>>> exit(0);
>>>> #-----------------------
>>>>
>>>> Result:
>>>> strobel@s114-intel:~/projekte/PHP> ./magicmethods.php
>>>> ----- creating class
>>>> --> call C1::__construct
>>>> ----- serializing class
>>>> --> call C1::__sleep
>>>> ----- deserializing class
>>>> --> call C1::__wakeup
>>>> ----- deleting first class
>>>> --> call C1::__destruct
>>>> ----- deleting unserialized class
>>>> --> call C1::__destruct
>>>>
>>>> What exactly did you criticize?
>>>>
>>>> /Str.
>>> Look at it again. You have two destructor calls but only one
>>> constructor call. A
>>> direct violation of OO principles.
>>>
>>> And BTW - I said nothing about serializing.
>>>
>>> You really do need to learn to read.
>>>
>>
>> No evasions, get to the point. I have one explicit constructor, and
>> one wakeup which
>> is a constructor.
>>
>> What did you talk about if not about serializing?
>>
>> /Str.
>
>
> c'mon. Jerry just cut and pasted something he read somewhere.
>
> Its not as if he understood what he was posting. Go easy on the poor old
> chap.
>
>
Ah, the biggest troll on Usenet once again shows just how stoopid he is.
He refuses to use his real name because he doesn't want everyone to
know he's neither a programmer or the electrical engineer he claims to
be. He's made that all too obvious so many times.
No, he's just a ditch digger who got fired because he couldn't figure
out which end of the shovel to use.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: out of sheer curiosity... [message #177549 is a reply to message #177546] |
Mon, 09 April 2012 09:29 |
M. Strobel
Messages: 386
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
Am 09.04.2012 02:24, schrieb Jerry Stuckle:
> On 4/8/2012 6:39 PM, M. Strobel wrote:
>> Am 08.04.2012 23:15, schrieb Jerry Stuckle:
>>> On 4/8/2012 4:50 PM, M. Strobel wrote:
>>>> Am 29.03.2012 22:11, schrieb Jerry Stuckle:
>>>> > On 3/29/2012 10:21 AM, Erwin Moller wrote:
>>>> >> On 3/29/2012 3:39 PM, Jerry Stuckle wrote:
>>>> >>> On 3/29/2012 8:33 AM, Erwin Moller wrote:
>>>> >>>> On 3/29/2012 12:46 PM, The Natural Philosopher wrote:
>>>> >>
>>>> >> <snip>
>>>> >>
>>>> >>>>> Its just another way of doing things and I let my understanding of the
>>>> >>>>> problem guide me, not a set of arbitrary rules.
>>>> >>>>
>>>> >>>> As it should!
>>>> >>>>
>>>> >>>> But what 'rules' are you referring to?
>>>> >>>>
>>>> >>>> PHP's OO is pretty straightforward.
>>>> >>>> I think they did a decent job implementing OO.(php 5 that is)
>>>> >>>>
>>>> >>>> Creating smart classes is up to the programmer.
>>>> >>>> I am not aware of any extra 'rules'.
>>>> >>>>
>>>> >>>> Are you maybe referring to all kinds of design patterns scattered around
>>>> >>>> the web?
>>>> >>>> (In which case I tend to agree, because implementing other people's
>>>> >>>> solutions can take the fun out of programming. But reading them never
>>>> >>>> hurts. And when you agree to a certain approach you can even decide to
>>>> >>>> follow it yourself. It is all up to you, the programmer.)
>>>> >>>>
>>>> >>>
>>>> >>> Any rules TNP doesn't bother to understand are "arbitrary" in his mind.
>>>> >>> He doesn't even like having to follow PHP syntax rules - as he has also
>>>> >>> said in the past.
>>>> >>>
>>>> >>> But I disagree that PHP 5's implementation of OO is decent. I think it's
>>>> >>> half-assed at best. Truly written by people who have no understanding of
>>>> >>> OO. But then that can be said of a lot of PHP.
>>>> >>>
>>>> >>
>>>> >> Jerry,
>>>> >>
>>>> >> What are your main objections to the PHP5's OO approach?
>>>> >>
>>>> >> For myself: I must say I love its simplicity.
>>>> >> (Simplicity is a Good Thing in my opinion.)
>>>> >>
>>>> >>
>>>> >
>>>> > Well, to start with, the lack of function overloading. It is quite a good
>>>> > feature to
>>>> > be able to overload functions - especially constructors. And because of that, you
>>>> > have to run through all kinds of hoops when doing things like storing an object in
>>>> > the $_SESSION.
>>>> >
>>>> > Even then it doesn't work. When you store an object in the $_SESSION, the object's
>>>> > destructor is called at the end of the script, but on the next script the
>>>> > constructor
>>>> > is never called. A direct violation of OO principles.
>>>>
>>>> Works fine here. Test script:
>>>> #!/usr/local/bin/php
>>>> <?php
>>>>
>>>> class C1 {
>>>> public $var1 = 'M.';
>>>> public $var2 = 'Strobel';
>>>> function __construct() {
>>>> echo "\t--> call ". __METHOD__.PHP_EOL;
>>>> }
>>>> function __destruct() {
>>>> echo "\t--> call ". __METHOD__.PHP_EOL;
>>>> }
>>>> function __sleep() {
>>>> echo "\t--> call ". __METHOD__.PHP_EOL;
>>>> return array('var1','var2');
>>>> }
>>>> function __wakeup() {
>>>> echo "\t--> call ". __METHOD__.PHP_EOL;
>>>> }
>>>> } // end class C1
>>>>
>>>> echo "----- creating class\n";
>>>> $c = new C1;
>>>> echo "----- serializing class\n";
>>>> $ser = serialize($c);
>>>> echo "----- deserializing class\n";
>>>> $cc = unserialize($ser);
>>>> echo "----- deleting first class\n";
>>>> unset($c);
>>>> echo "----- deleting unserialized class\n";
>>>> unset($cc);
>>>> exit(0);
>>>> #-----------------------
>>>>
>>>> Result:
>>>> strobel@s114-intel:~/projekte/PHP> ./magicmethods.php
>>>> ----- creating class
>>>> --> call C1::__construct
>>>> ----- serializing class
>>>> --> call C1::__sleep
>>>> ----- deserializing class
>>>> --> call C1::__wakeup
>>>> ----- deleting first class
>>>> --> call C1::__destruct
>>>> ----- deleting unserialized class
>>>> --> call C1::__destruct
>>>>
>>>> What exactly did you criticize?
>>>>
>>>> /Str.
>>>
>>> Look at it again. You have two destructor calls but only one constructor call. A
>>> direct violation of OO principles.
>>>
>>> And BTW - I said nothing about serializing.
>>>
>>> You really do need to learn to read.
>>>
>>
>> No evasions, get to the point. I have one explicit constructor, and one wakeup which
>> is a constructor.
>>
>> What did you talk about if not about serializing?
>>
>> /Str.
>
> I know a one-to-one correspondence is very difficult for someone of your (lack of)
> intellect to understand, but I'll try again anyway.
This is evasion, or your troll rite.
> You have these calls:
> --> call C1::__construct
>
> That's ONE call to a constructor.
>
>
> --> call C1::__destruct
> --> call C1::__destruct
>
> That's TWO calls to destructors. IOW, an object was constructed without calling a
> constructor. This is a direct violation of OO principals (all objects must have
> exactly one constructor call and one destructor call).
>
> And ONE does not equal TWO. wakeup() is not a constructor, any more than sleep() is
> a destructor (and if sleep() were a destructor, then you would see a call to sleep()
> and a call to the destructor).
You should admit that serialize() is a special function that creates a frozen
portable copy of an object. The object loses it's identity in the process, but keeps
it's data. The calls to sleep() and wakeup() are okay.
> And I was referring to storing in a session, not serializing the data, i.e.
>
> $_SESSION['stupid'] = $idiot;
You could probably not work in a team, because you can't talk/write. You could
certainly not work as a teacher.
This is very interesting, and I never ran into this in my 20000+ lines of code
(current project), because I have a feeling of what makes sense. I always serialize
my objects myself.
The handling of objects in session variables seems broke. This is IMO no defect in
the object model, but in the session code.
Here is the test code, see yourself:
<head>
<title>object activity in session</title>
<meta http-equiv="content-type"
content="text/html;charset=utf-8" />
</head>
<body>
<h2>test script, see source code</h2>
<pre>
<?php
session_start();
if (!isset($_SESSION['cnt'])) $_SESSION['cnt']=1;
class C1 {
public $var1 = 'M. ';
public $var2 = 'Strobel';
function __construct() {
echo "\t--> call ". __METHOD__.PHP_EOL;
}
function __destruct() {
echo "\t--> call ". __METHOD__.PHP_EOL;
}
function __sleep() {
echo "\t--> call ". __METHOD__.PHP_EOL;
return array('var1','var2');
}
function __wakeup() {
echo "\t--> call ". __METHOD__.PHP_EOL;
}
function greet() { echo 'Hi, I am ',$this->var1, $this->var2, "\n"; }
} // end class C1
echo "This is call number ", $_SESSION['cnt'], "\n";
switch ($_SESSION['cnt']) {
case 1:
echo "creating object directly in session:\n";
$_SESSION['c1'] = new C1;
break;
case 2:
echo "Trying to access object in session:\n";
$_SESSION['c1']->greet();
break;
case 3:
echo "clearing session to start over, return code: ", session_destroy(), "\n";
break;
default:
echo "\nThis should not happen.\n";
}
$_SESSION['cnt']++;
?>
</pre></body></html>
/Str.
|
|
|
|
| Re: out of sheer curiosity... [message #177550 is a reply to message #177549] |
Mon, 09 April 2012 12:27 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 4/9/2012 5:29 AM, M. Strobel wrote:
>
> You should admit that serialize() is a special function that creates a frozen
> portable copy of an object. The object loses it's identity in the process, but keeps
> it's data. The calls to sleep() and wakeup() are okay.
>
It doesn't make any difference what serialize is. OO requires exactly
one constructor and one destructor call for every object. Other
languages such as C++, SmallTalk and Java handle it fine.
sleep() and wakeup() are not constructors or destructors, and have a
different purpose.
>> And I was referring to storing in a session, not serializing the data, i.e.
>>
>> $_SESSION['stupid'] = $idiot;
>
> You could probably not work in a team, because you can't talk/write. You could
> certainly not work as a teacher.
I've been working in team environments for over 40 years. I have been
managing multi-programmer projects for over 25 years. And I have been
teaching for corporations (mostly Fortune 500) for over 20 years -
mainly C, C++, Java and OOAD (although some others also).
But then my students are intelligent. You wouldn't last a month there.
>
> This is very interesting, and I never ran into this in my 20000+ lines of code
> (current project), because I have a feeling of what makes sense. I always serialize
> my objects myself.
>
Shows how stoopid you really are. Glad you aren't on one of my projects
- you wouldn't last long (see above).
> The handling of objects in session variables seems broke. This is IMO no defect in
> the object model, but in the session code.
>
It is a flat out conflict in OO requirements. It has nothing to do with
sessions.
> Here is the test code, see yourself:
>
<snip>
Who gives a crap?
The bottom line is that PHP violates OO principles. No other language
does so. But then I'm sure you don't have any experience with other
languages.
> /Str.
You really are showing how ignorant of basic OO principles you are.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: out of sheer curiosity... [message #177551 is a reply to message #177550] |
Mon, 09 April 2012 13:20 |
Thomas Mlynarczyk
Messages: 131
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
Jerry Stuckle schrieb:
> It doesn't make any difference what serialize is. OO requires exactly
> one constructor and one destructor call for every object.
Says who? What does object orientation have to do with constructors and
destructors? They're not required.
A constructor is called when a new object is constructed. A serialized
object has already been constructed so there's no point in calling its
constructor again when it is unserialized. In fact, the process of
serializing/unserializing creates a copy of the original object. (The
same holds for clone'd objects, by the way).
Greetings,
Thomas
--
Ce n'est pas parce qu'ils sont nombreux à avoir tort qu'ils ont raison!
(Coluche)
|
|
|
|
| Re: out of sheer curiosity... [message #177552 is a reply to message #177551] |
Mon, 09 April 2012 16:03 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 4/9/2012 9:20 AM, Thomas Mlynarczyk wrote:
> Jerry Stuckle schrieb:
>
>> It doesn't make any difference what serialize is. OO requires exactly
>> one constructor and one destructor call for every object.
>
> Says who? What does object orientation have to do with constructors and
> destructors? They're not required.
>
Check any of the recognized OO experts - Booch and Yourdon, for
instance. Constructors are used to build objects, and destructors are
used to clean up objects. They have EVERYTHING to do with object
orientation!
And this is true of ALL true OO languages - such as C++, Java and
Smalltalk.
> A constructor is called when a new object is constructed. A serialized
> object has already been constructed so there's no point in calling its
> constructor again when it is unserialized. In fact, the process of
> serializing/unserializing creates a copy of the original object. (The
> same holds for clone'd objects, by the way).
>
> Greetings,
> Thomas
>
No, a serialized object is NOT necessarily constructed. It may have,
for instance, references to external resources which are no longer
available, such as a database connection. When this is the case, the
object is no longer valid - because the external resource is no longer
available.
One of the basic tenets of OO is that an object is responsible for its
own validity. An object must always be valid (or, if it is not valid
for some reason, not allow operations on it which depend on it being valid).
The __clone() method is a form of a constructor. But wakeup() isn't.
And if you argue that wakeup() is a form of a constructor, then you have
to argue that sleep() is a form of a destructor - in which case it would
be invalid to call the destructor after calling sleep().
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: out of sheer curiosity... [message #177553 is a reply to message #177552] |
Mon, 09 April 2012 18:04 |
Thomas Mlynarczyk
Messages: 131
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
Jerry Stuckle schrieb:
> The __clone() method is a form of a constructor. But wakeup() isn't.
Neither is. Cloning simply copies a previously constructed object while
__wakeup() changes the state of a previously constructed object.
> And if you argue that wakeup() is a form of a constructor,
I don't and never did.
> then you have
> to argue that sleep() is a form of a destructor - in which case it would
> be invalid to call the destructor after calling sleep().
Serialization creates a kind of "frozen" copy of an object. The original
object continues to exist and its destructor is called as expected.
Later, the "frozen" copy is "warmed up" and can pretend to be the
original object, but it is not the same object. The __sleep() and
__wakeup() methods simply assist with the freezing and warming up and
have nothing to do with the copying.
To sum it up: A new object can be created by either constructing it
(which calls __construct()) or by copying an existing object (via clone
or via serialization) and this happens without calling __construct() on
the copy since the object is already constructed. And this explains why
there may be more __destruct() calls than __construct() calls in a script.
Greetings,
Thomas
--
Ce n'est pas parce qu'ils sont nombreux à avoir tort qu'ils ont raison!
(Coluche)
|
|
|
|
| Re: out of sheer curiosity... [message #177554 is a reply to message #177553] |
Mon, 09 April 2012 18:37 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 4/9/2012 2:04 PM, Thomas Mlynarczyk wrote:
> Jerry Stuckle schrieb:
>
>> The __clone() method is a form of a constructor. But wakeup() isn't.
>
> Neither is. Cloning simply copies a previously constructed object while
> __wakeup() changes the state of a previously constructed object.
>
Yes, __clone() is a form of a constructor. It creates a new object from
an existing object of the same type. In C++ this would be known as the
copy constructor, for instance. In Java it is the clone() method. Both
are considered constructors.
Also, when the object is serialized, it no longer is an object. It has
state but no behavior - the data are there but not the methods.
So when it is deserialized, a new object is created and by definition a
constructor must be called.
>> And if you argue that wakeup() is a form of a constructor,
>
> I don't and never did.
>
>> then you have to argue that sleep() is a form of a destructor - in
>> which case it would be invalid to call the destructor after calling
>> sleep().
>
> Serialization creates a kind of "frozen" copy of an object. The original
> object continues to exist and its destructor is called as expected.
> Later, the "frozen" copy is "warmed up" and can pretend to be the
> original object, but it is not the same object. The __sleep() and
> __wakeup() methods simply assist with the freezing and warming up and
> have nothing to do with the copying.
>
No, all serialization does is save the contents of the object. It is no
longer an object. The call to the original object's destructor is
correct. And, as you mentioned, when it is deserialized, it is no
longer the same object - it is a new one, so a constructor must be called.
> To sum it up: A new object can be created by either constructing it
> (which calls __construct()) or by copying an existing object (via clone
> or via serialization) and this happens without calling __construct() on
> the copy since the object is already constructed. And this explains why
> there may be more __destruct() calls than __construct() calls in a script.
>
> Greetings,
> Thomas
>
In object oriented programming, a new object can ONLY be created by
calling a constructor. As noted above, different languages have
different terms for them. But a constructor MUST be called according to
OO principles.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: out of sheer curiosity... [message #177555 is a reply to message #177553] |
Mon, 09 April 2012 18:50 |
Scott Johnson
Messages: 196
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
On 4/9/2012 11:04 AM, Thomas Mlynarczyk wrote:
>
> Serialization creates a kind of "frozen" copy of an object. The original
> object continues to exist and its destructor is called as expected.
> Later, the "frozen" copy is "warmed up" and can pretend to be the
> original object, but it is not the same object. The __sleep() and
> __wakeup() methods simply assist with the freezing and warming up and
> have nothing to do with the copying.
I am not even near to being a voice for OOP in php but something ran
through my mind when i read this.
I use serialize to save form data from time to time into a DB. Easier
then having to have a separate column for each field (with obvious query
drawbacks - but I digress)
What would be the reason to serialize an object other then to save it
for later use, and at the time I can't really come up with a reason for
that in my mind (lack of experience in this area I suppose)
Now if you are saving it for later use then the original object would no
longer exist and the external resources as Jerry explained would no
longer be available if not for the constructor.
I am not sure if I am even making sense, this just kind of went across
my mind as i was reading.
Scotty
|
|
|
|
| Re: out of sheer curiosity... [message #177558 is a reply to message #177554] |
Mon, 09 April 2012 20:50 |
Thomas Mlynarczyk
Messages: 131
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
Jerry Stuckle schrieb:
> In object oriented programming, a new object can ONLY be created by
> calling a constructor. As noted above, different languages have
> different terms for them. But a constructor MUST be called according to
> OO principles.
Just to avoid confusion: When a new object is created, PHP must do some
work under the hood like allocating memory etc. and this of course is
"construction" work which is always done and in that sense a constructor
is indeed always called.
But after that, there is (or is not) the call to __construct(). And now
that I think of it, the name __construct() is actually not quite
correct, since the actual construction of the object is already done at
that point. What __construct() really does is perform some
initialization (in Python, the corresponding method is indeed called
__init__()).
And this initialization is not needed (or might even prove harmful) when
the object is copied rather than created from scratch, because in that
case the initialization was already done on the original object and the
copy was thus created from an already initialized object and it will
"inherit" the initialized state. Instead, there are __clone() and
__wakeup() which replace __construct() and can do different
initialization tasks depending on how the object was created.
Therefore I must correct my earlier remark about neither __clone() nor
__wakeup() being constructors: __construct(), __clone() and __wakeup()
are all "of the same kind" -- performing initialization of an object
depending on how it was created.
On the other hand, __sleep() is not a destructor, because nothing is
destroyed when it is called. Note that __sleep() is supposed to return
an array, contrary to __destruct(). So, while the names __sleep() and
__wakeup() suggest a correspondence like __destruct() and __construct(),
this is not the case, since __sleep() is called on the original object,
while __wakeup() is called on the resurrected copy, so they're not
called on the same object.
Anyway, I must thank you for making me think more thoroughly about this.
Greetings,
Thomas
--
Ce n'est pas parce qu'ils sont nombreux à avoir tort qu'ils ont raison!
(Coluche)
|
|
|
|
| Re: out of sheer curiosity... [message #177560 is a reply to message #177555] |
Mon, 09 April 2012 21:03 |
Thomas Mlynarczyk
Messages: 131
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
Scott Johnson schrieb:
> What would be the reason to serialize an object other then to save it
> for later use, and at the time I can't really come up with a reason for
> that in my mind (lack of experience in this area I suppose)
True, this seems to be the most common use case: Make the object persist
between different HTTP requests.
> Now if you are saving it for later use then the original object would no
> longer exist and the external resources as Jerry explained would no
> longer be available if not for the constructor.
The point is that an unserialized object would usually be in a different
state than a "fresh" object created using the `new` operator and thus
require different initialization tasks to be performed. That's why
different magic methods exist:
__construct(): Object is "fresh", created using `new`
__clone(): Object was copied from another object
__wakeup(): Object was unserialized
Greetings,
Thomas
--
Ce n'est pas parce qu'ils sont nombreux à avoir tort qu'ils ont raison!
(Coluche)
|
|
|
|
| Re: out of sheer curiosity... [message #177562 is a reply to message #177560] |
Mon, 09 April 2012 22:27 |
Scott Johnson
Messages: 196
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
On 4/9/2012 2:03 PM, Thomas Mlynarczyk wrote:
> Scott Johnson schrieb:
>
>> What would be the reason to serialize an object other then to save it
>> for later use, and at the time I can't really come up with a reason
>> for that in my mind (lack of experience in this area I suppose)
>
> True, this seems to be the most common use case: Make the object persist
> between different HTTP requests.
>
>> Now if you are saving it for later use then the original object would
>> no longer exist and the external resources as Jerry explained would no
>> longer be available if not for the constructor.
>
> The point is that an unserialized object would usually be in a different
> state than a "fresh" object created using the `new` operator and thus
> require different initialization tasks to be performed. That's why
> different magic methods exist:
>
> __construct(): Object is "fresh", created using `new`
> __clone(): Object was copied from another object
> __wakeup(): Object was unserialized
>
> Greetings,
> Thomas
>
OK I see.
I had not even thought about the need for creating the object from
either new or from a copied version.
Thanks for squeezing my brain.
Scotty
|
|
|
|
| Re: out of sheer curiosity... [message #177564 is a reply to message #177558] |
Tue, 10 April 2012 00:17 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 4/9/2012 4:50 PM, Thomas Mlynarczyk wrote:
> Jerry Stuckle schrieb:
>
>> In object oriented programming, a new object can ONLY be created by
>> calling a constructor. As noted above, different languages have
>> different terms for them. But a constructor MUST be called according
>> to OO principles.
>
> Just to avoid confusion: When a new object is created, PHP must do some
> work under the hood like allocating memory etc. and this of course is
> "construction" work which is always done and in that sense a constructor
> is indeed always called.
>
No, memory allocation is NOT the same as a constructor. Memory
allocation makes space for the object. The constructor initializes it.
> But after that, there is (or is not) the call to __construct(). And now
> that I think of it, the name __construct() is actually not quite
> correct, since the actual construction of the object is already done at
> that point. What __construct() really does is perform some
> initialization (in Python, the corresponding method is indeed called
> __init__()).
>
In OO terminology, the correct term is "constructor". I'm not familiar
with Python, so I can't say what Python calls it. But the name is not
as important as the job.
> And this initialization is not needed (or might even prove harmful) when
> the object is copied rather than created from scratch, because in that
> case the initialization was already done on the original object and the
> copy was thus created from an already initialized object and it will
> "inherit" the initialized state. Instead, there are __clone() and
> __wakeup() which replace __construct() and can do different
> initialization tasks depending on how the object was created.
>
Initialization is NEVER harmful if it is done properly. That's the
whole purpose of initialization!. wakeup() is NOT a constructor - any
more than sleep() is a destructor.
> Therefore I must correct my earlier remark about neither __clone() nor
> __wakeup() being constructors: __construct(), __clone() and __wakeup()
> are all "of the same kind" -- performing initialization of an object
> depending on how it was created.
>
wakeup() is not a constructor. If you consider it a constructor, then
you must also consider sleep() to be a destructor - in which case it
would be illegal to call the destructor after calling sleep().
> On the other hand, __sleep() is not a destructor, because nothing is
> destroyed when it is called. Note that __sleep() is supposed to return
> an array, contrary to __destruct(). So, while the names __sleep() and
> __wakeup() suggest a correspondence like __destruct() and __construct(),
> this is not the case, since __sleep() is called on the original object,
> while __wakeup() is called on the resurrected copy, so they're not
> called on the same object.
>
It is the opposite of wakeup() - just like __construct() is the opposite
of __destruct(). You can't have it both ways.
> Anyway, I must thank you for making me think more thoroughly about this.
>
> Greetings,
> Thomas
>
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: out of sheer curiosity... [message #177565 is a reply to message #177560] |
Tue, 10 April 2012 00:22 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 4/9/2012 5:03 PM, Thomas Mlynarczyk wrote:
> Scott Johnson schrieb:
>
>> What would be the reason to serialize an object other then to save it
>> for later use, and at the time I can't really come up with a reason
>> for that in my mind (lack of experience in this area I suppose)
>
> True, this seems to be the most common use case: Make the object persist
> between different HTTP requests.
>
Objects NEVER persist between different HTTP requests. By definition,
HTTP is a transactional environment and at the end of the request any
objects are destroyed. Data may be saved between requests (i.e.
$_SESSION in PHP, a database, etc.). But these are not objects.
Objects by definition have state and behavior. Only the state can
persist between transactions; behavior never can - which is why objects
need to be reconstructed.
>> Now if you are saving it for later use then the original object would
>> no longer exist and the external resources as Jerry explained would no
>> longer be available if not for the constructor.
>
> The point is that an unserialized object would usually be in a different
> state than a "fresh" object created using the `new` operator and thus
> require different initialization tasks to be performed. That's why
> different magic methods exist:
>
Which is why objects can never persist across transactions. A new
object requires a constructor, under OO rules.
> __construct(): Object is "fresh", created using `new`
> __clone(): Object was copied from another object
> __wakeup(): Object was unserialized
>
> Greetings,
> Thomas
>
Both __construct() and __clone() are types of constructors. __wakeup()
is not (unless you consider sleep() to be a destructor - see above).
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]