Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.php > #5244 > unrolled thread
| Started by | "Leonardo Azpurua" <leonardo@exmvps.org> |
|---|---|
| First post | 2012-03-27 12:31 -0430 |
| Last post | 2012-04-12 07:45 -0400 |
| Articles | 20 on this page of 96 — 10 participants |
Back to article view | Back to comp.lang.php
out of sheer curiosity... "Leonardo Azpurua" <leonardo@exmvps.org> - 2012-03-27 12:31 -0430
Re: out of sheer curiosity... "Álvaro G. Vicario" <alvaro.NOSPAMTHANX@demogracia.com.invalid> - 2012-03-27 19:06 +0200
Re: out of sheer curiosity... "Leonardo Azpurua" <leonardo@exmvps.org> - 2012-03-27 13:04 -0430
Re: out of sheer curiosity... Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-03-28 21:12 +0200
Re: out of sheer curiosity... "Leonardo Azpurua" <leonardo@exmvps.org> - 2012-03-28 20:23 -0430
Re: out of sheer curiosity... "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2012-03-29 10:00 +0200
Re: out of sheer curiosity... "Leonardo Azpurua" <leonardo@exmvps.org> - 2012-03-29 05:23 -0430
Re: out of sheer curiosity... The Natural Philosopher <tnp@invalid.invalid> - 2012-03-29 11:46 +0100
Re: out of sheer curiosity... "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2012-03-29 14:02 +0200
Re: out of sheer curiosity... Erwin Moller <erwinmollerusenet@xs4all.nl> - 2012-03-29 14:33 +0200
Re: out of sheer curiosity... The Natural Philosopher <tnp@invalid.invalid> - 2012-03-29 14:37 +0100
Re: out of sheer curiosity... Erwin Moller <erwinmollerusenet@xs4all.nl> - 2012-03-29 15:59 +0200
Re: out of sheer curiosity... The Natural Philosopher <tnp@invalid.invalid> - 2012-03-29 17:58 +0100
Re: out of sheer curiosity... Jerry Stuckle <jstucklex@attglobal.net> - 2012-03-29 09:39 -0400
Re: out of sheer curiosity... Erwin Moller <erwinmollerusenet@xs4all.nl> - 2012-03-29 16:21 +0200
Re: out of sheer curiosity... The Natural Philosopher <tnp@invalid.invalid> - 2012-03-29 18:09 +0100
Re: out of sheer curiosity... Tim Streater <timstreater@greenbee.net> - 2012-03-29 22:07 +0100
Re: out of sheer curiosity... "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2012-03-29 23:43 +0200
Re: out of sheer curiosity... The Natural Philosopher <tnp@invalid.invalid> - 2012-03-30 04:52 +0100
Re: out of sheer curiosity... Jerry Stuckle <jstucklex@attglobal.net> - 2012-03-29 16:11 -0400
Re: out of sheer curiosity... Tim Streater <timstreater@greenbee.net> - 2012-03-29 22:01 +0100
Re: out of sheer curiosity... Jerry Stuckle <jstucklex@attglobal.net> - 2012-03-29 19:29 -0400
Re: out of sheer curiosity... "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2012-04-08 22:50 +0200
Re: out of sheer curiosity... Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-08 17:15 -0400
Re: out of sheer curiosity... "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2012-04-09 00:39 +0200
Re: out of sheer curiosity... The Natural Philosopher <tnp@invalid.invalid> - 2012-04-09 00:59 +0100
Re: out of sheer curiosity... Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-08 20:28 -0400
Re: out of sheer curiosity... Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-08 20:24 -0400
Re: out of sheer curiosity... "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2012-04-09 11:29 +0200
Re: out of sheer curiosity... Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-09 08:27 -0400
Re: out of sheer curiosity... Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2012-04-09 15:20 +0200
Re: out of sheer curiosity... Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-09 12:03 -0400
Re: out of sheer curiosity... Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2012-04-09 20:04 +0200
Re: out of sheer curiosity... Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-09 14:37 -0400
Re: out of sheer curiosity... Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2012-04-09 22:50 +0200
Re: out of sheer curiosity... Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-09 20:17 -0400
Re: out of sheer curiosity... "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2012-04-10 10:05 +0200
Re: out of sheer curiosity... Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2012-04-10 13:28 +0200
Re: out of sheer curiosity... "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2012-04-10 18:54 +0200
Re: out of sheer curiosity... Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2012-04-10 20:10 +0200
Re: out of sheer curiosity... "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2012-04-10 20:23 +0200
Re: out of sheer curiosity... Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2012-04-10 23:17 +0200
Re: out of sheer curiosity... Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-10 17:11 -0400
Re: out of sheer curiosity... Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2012-04-10 23:30 +0200
Re: out of sheer curiosity... Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-10 19:43 -0400
Re: out of sheer curiosity... Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-10 17:08 -0400
Re: out of sheer curiosity... "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2012-04-11 10:40 +0200
Re: out of sheer curiosity... Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-10 07:58 -0400
Re: out of sheer curiosity... Tim Streater <timstreater@greenbee.net> - 2012-04-10 16:04 +0100
Re: out of sheer curiosity... Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-10 12:10 -0400
Re: out of sheer curiosity... Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2012-04-10 18:18 +0200
Re: out of sheer curiosity... The Natural Philosopher <tnp@invalid.invalid> - 2012-04-10 18:20 +0100
Re: out of sheer curiosity... "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2012-04-10 19:31 +0200
Re: out of sheer curiosity... Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-10 17:20 -0400
Re: out of sheer curiosity... Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2012-04-10 23:57 +0200
Re: out of sheer curiosity... Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-10 19:50 -0400
Re: out of sheer curiosity... Tim Streater <timstreater@greenbee.net> - 2012-04-10 17:41 +0100
Re: out of sheer curiosity... Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2012-04-10 17:25 +0200
Re: out of sheer curiosity... Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-10 12:16 -0400
Re: out of sheer curiosity... Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2012-04-10 13:44 +0200
Re: out of sheer curiosity... Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-10 08:04 -0400
Re: out of sheer curiosity... Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2012-04-10 17:37 +0200
Re: out of sheer curiosity... Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-10 12:19 -0400
Re: out of sheer curiosity... Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2012-04-10 18:44 +0200
Re: out of sheer curiosity... Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-10 17:23 -0400
Re: out of sheer curiosity... Scott Johnson <noonehome@chalupasworld.com> - 2012-04-09 11:50 -0700
Re: out of sheer curiosity... Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2012-04-09 23:03 +0200
Re: out of sheer curiosity... Scott Johnson <noonehome@chalupasworld.com> - 2012-04-09 15:27 -0700
Re: out of sheer curiosity... Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-09 20:25 -0400
Re: out of sheer curiosity... Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2012-04-10 12:48 +0200
Re: out of sheer curiosity... Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-10 08:06 -0400
Re: out of sheer curiosity... "Leonardo Azpurua" <leonardo@exmvps.org> - 2012-04-10 07:52 -0430
Re: out of sheer curiosity... Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-10 12:20 -0400
Re: out of sheer curiosity... "Leonardo Azpurua" <leonardo@exmvps.org> - 2012-04-10 12:03 -0430
Re: out of sheer curiosity... Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-10 17:28 -0400
Re: out of sheer curiosity... Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2012-04-11 00:13 +0200
Re: out of sheer curiosity... Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-10 19:53 -0400
Re: out of sheer curiosity... Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2012-04-11 22:17 +0200
Re: out of sheer curiosity... Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-11 16:30 -0400
Re: out of sheer curiosity... Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-09 20:22 -0400
Re: out of sheer curiosity... Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2012-04-10 12:43 +0200
Re: out of sheer curiosity... Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-10 08:11 -0400
Re: out of sheer curiosity... Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2012-04-10 18:15 +0200
Re: out of sheer curiosity... "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2012-04-10 19:09 +0200
Re: out of sheer curiosity... Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2012-04-10 20:17 +0200
Re: out of sheer curiosity... "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2012-04-10 20:25 +0200
Re: out of sheer curiosity... Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2012-04-10 23:21 +0200
Re: out of sheer curiosity... Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-10 17:34 -0400
Re: out of sheer curiosity... Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2012-04-11 01:00 +0200
Re: out of sheer curiosity... Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-10 19:54 -0400
Re: out of sheer curiosity... Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2012-04-11 22:10 +0200
Re: out of sheer curiosity... Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-11 16:31 -0400
Re: out of sheer curiosity... Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2012-04-11 22:40 +0200
Re: out of sheer curiosity... Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-12 00:02 -0400
Re: out of sheer curiosity... "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2012-04-12 12:00 +0200
Re: out of sheer curiosity... Jerry Stuckle <jstucklex@attglobal.net> - 2012-04-12 07:45 -0400
Page 1 of 5 [1] 2 3 4 5 Next page →
| From | "Leonardo Azpurua" <leonardo@exmvps.org> |
|---|---|
| Date | 2012-03-27 12:31 -0430 |
| Subject | out of sheer curiosity... |
| Message-ID | <jksrmr$rgq$1@dont-email.me> |
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. --
[toc] | [next] | [standalone]
| From | "Álvaro G. Vicario" <alvaro.NOSPAMTHANX@demogracia.com.invalid> |
|---|---|
| Date | 2012-03-27 19:06 +0200 |
| Message-ID | <jkss34$trc$1@dont-email.me> |
| In reply to | #5244 |
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
--
[toc] | [prev] | [next] | [standalone]
| From | "Leonardo Azpurua" <leonardo@exmvps.org> |
|---|---|
| Date | 2012-03-27 13:04 -0430 |
| Message-ID | <jkstn8$967$1@dont-email.me> |
| In reply to | #5245 |
(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.NOSPAMTHANX@demogracia.com.invalid> escribió
en el mensaje news:jkss34$trc$1@dont-email.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 programación web: http://borrame.com
> -- Mi web de humor satinado: http://www.demogracia.com
> --
[toc] | [prev] | [next] | [standalone]
| From | Thomas 'PointedEars' Lahn <PointedEars@web.de> |
|---|---|
| Date | 2012-03-28 21:12 +0200 |
| Message-ID | <17777949.TfjZNtg3zH@PointedEars.de> |
| In reply to | #5244 |
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).
[toc] | [prev] | [next] | [standalone]
| From | "Leonardo Azpurua" <leonardo@exmvps.org> |
|---|---|
| Date | 2012-03-28 20:23 -0430 |
| Message-ID | <jl0boo$461$1@dont-email.me> |
| In reply to | #5248 |
"Thomas 'PointedEars' Lahn" <PointedEars@web.de> escribió en el mensaje news:17777949.TfjZNtg3zH@PointedEars.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! --
[toc] | [prev] | [next] | [standalone]
| From | "M. Strobel" <sorry_no_mail_here@nowhere.dee> |
|---|---|
| Date | 2012-03-29 10:00 +0200 |
| Message-ID | <9tij5fFmi8U1@mid.uni-berlin.de> |
| In reply to | #5249 |
Am 29.03.2012 02:53, schrieb Leonardo Azpurua: > "Thomas 'PointedEars' Lahn" <PointedEars@web.de> escribió en el mensaje > news:17777949.TfjZNtg3zH@PointedEars.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.
[toc] | [prev] | [next] | [standalone]
| From | "Leonardo Azpurua" <leonardo@exmvps.org> |
|---|---|
| Date | 2012-03-29 05:23 -0430 |
| Message-ID | <jl1bei$ckh$1@dont-email.me> |
| In reply to | #5250 |
"M. Strobel" <sorry_no_mail_here@nowhere.dee> escribió en el mensaje news:9tij5fFmi8U1@mid.uni-berlin.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. --
[toc] | [prev] | [next] | [standalone]
| From | The Natural Philosopher <tnp@invalid.invalid> |
|---|---|
| Date | 2012-03-29 11:46 +0100 |
| Message-ID | <jl1ehv$86a$1@news.albasani.net> |
| In reply to | #5251 |
Leonardo Azpurua wrote: > "M. Strobel" <sorry_no_mail_here@nowhere.dee> escribi� en el mensaje > news:9tij5fFmi8U1@mid.uni-berlin.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.
[toc] | [prev] | [next] | [standalone]
| From | "M. Strobel" <sorry_no_mail_here@nowhere.dee> |
|---|---|
| Date | 2012-03-29 14:02 +0200 |
| Message-ID | <9tj1a3FnmU1@mid.uni-berlin.de> |
| In reply to | #5252 |
Am 29.03.2012 12:46, schrieb The Natural Philosopher: > Leonardo Azpurua wrote: >> "M. Strobel" <sorry_no_mail_here@nowhere.dee> escribi� en el mensaje >> news:9tij5fFmi8U1@mid.uni-berlin.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.
[toc] | [prev] | [next] | [standalone]
| From | Erwin Moller <erwinmollerusenet@xs4all.nl> |
|---|---|
| Date | 2012-03-29 14:33 +0200 |
| Message-ID | <4f74567c$0$6887$e4fe514c@news2.news.xs4all.nl> |
| In reply to | #5252 |
On 3/29/2012 12:46 PM, The Natural Philosopher wrote: > Leonardo Azpurua wrote: >> "M. Strobel" <sorry_no_mail_here@nowhere.dee> escribi� en el mensaje >> news:9tij5fFmi8U1@mid.uni-berlin.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
[toc] | [prev] | [next] | [standalone]
| From | The Natural Philosopher <tnp@invalid.invalid> |
|---|---|
| Date | 2012-03-29 14:37 +0100 |
| Message-ID | <jl1oj4$rqf$1@news.albasani.net> |
| In reply to | #5254 |
Erwin Moller wrote: > On 3/29/2012 12:46 PM, The Natural Philosopher wrote: >> Leonardo Azpurua wrote: >>> "M. Strobel" <sorry_no_mail_here@nowhere.dee> escribi� en el mensaje >>> news:9tij5fFmi8U1@mid.uni-berlin.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.
[toc] | [prev] | [next] | [standalone]
| From | Erwin Moller <erwinmollerusenet@xs4all.nl> |
|---|---|
| Date | 2012-03-29 15:59 +0200 |
| Message-ID | <4f746ac3$0$6901$e4fe514c@news2.news.xs4all.nl> |
| In reply to | #5255 |
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
[toc] | [prev] | [next] | [standalone]
| From | The Natural Philosopher <tnp@invalid.invalid> |
|---|---|
| Date | 2012-03-29 17:58 +0100 |
| Message-ID | <jl24at$k48$1@news.albasani.net> |
| In reply to | #5257 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2012-03-29 09:39 -0400 |
| Message-ID | <jl1omm$hdm$1@dont-email.me> |
| In reply to | #5254 |
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@nowhere.dee> escribi� en el mensaje >>> news:9tij5fFmi8U1@mid.uni-berlin.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@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Erwin Moller <erwinmollerusenet@xs4all.nl> |
|---|---|
| Date | 2012-03-29 16:21 +0200 |
| Message-ID | <4f746ff9$0$6918$e4fe514c@news2.news.xs4all.nl> |
| In reply to | #5256 |
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
[toc] | [prev] | [next] | [standalone]
| From | The Natural Philosopher <tnp@invalid.invalid> |
|---|---|
| Date | 2012-03-29 18:09 +0100 |
| Message-ID | <jl250b$lkq$1@news.albasani.net> |
| In reply to | #5258 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Tim Streater <timstreater@greenbee.net> |
|---|---|
| Date | 2012-03-29 22:07 +0100 |
| Message-ID | <timstreater-40AC09.22071029032012@news.individual.net> |
| In reply to | #5260 |
In article <jl250b$lkq$1@news.albasani.net>, The Natural Philosopher <tnp@invalid.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
[toc] | [prev] | [next] | [standalone]
| From | "M. Strobel" <sorry_no_mail_here@nowhere.dee> |
|---|---|
| Date | 2012-03-29 23:43 +0200 |
| Message-ID | <9tk3bmF84hU1@mid.uni-berlin.de> |
| In reply to | #5263 |
Am 29.03.2012 23:07, schrieb Tim Streater: > In article <jl250b$lkq$1@news.albasani.net>, > The Natural Philosopher <tnp@invalid.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.
[toc] | [prev] | [next] | [standalone]
| From | The Natural Philosopher <tnp@invalid.invalid> |
|---|---|
| Date | 2012-03-30 04:52 +0100 |
| Message-ID | <jl3al6$ol9$2@news.albasani.net> |
| In reply to | #5263 |
Tim Streater wrote: > In article <jl250b$lkq$1@news.albasani.net>, > The Natural Philosopher <tnp@invalid.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.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2012-03-29 16:11 -0400 |
| Message-ID | <jl2fl0$v97$1@dont-email.me> |
| In reply to | #5258 |
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@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
Page 1 of 5 [1] 2 3 4 5 Next page →
Back to top | Article view | comp.lang.php
csiph-web