PHP: Object Oriented Programming

[cyberlew15]

I didn't think weedpacket was right when I heard his post and He is not by no means should you learn javascript to benefit your actionscript or vica versa it does not work. JavaScript was the projenitor ECMA is simply a specification to which client side scripting languages can either conform to or not please read http://en.wikipedia.org/wiki/ECMAScript before flaming on and on. Yes modern javascript, Jscript, and Actionscript are ECMA based as in they conform to it's standards but in no way are they even remotely comparable. it's like trying to compare the propulsion systems of hovercrafts and sailboats they both travel across water but are fundamentally different only the basics are the same

[laserlight]

I didn't think weedpacket was right when I heard his post and He is not by no means should you learn javascript to benefit your actionscript or vica versa it does not work.

hmm... but Weedpacket said nothing about learning one to benefit the other - he merely stated what you confirmed, that the underlying language is the same, but otherwise they are different.

[cyberlew15]

Oh I must have Imagined this statement

Another thing to point out is that both Actionscript and Javascript are in fact both the same language - ECMAScript.

Oh yeah and I suppose i imaginged the rest of the post

The only difference lies in what is controlled by the objects and interfaces provided by the environment.

absolute rubbish actionscript utilises a much more advanced control of it's DOM(the flash DOM)

Also One is Compiled and the other is interpreted Once again Laserlightyou are playing semantics with words and not really understanding the underlying issues of the subjects. and again ECMA Script is not an underlying Language merely a specification for languages to comply to.

[laserlight]

Also One is Compiled and the other is interpreted

Such differences dont really count here - all compiled languages are interpreted at some level.

and not really understanding the underlying issues of the subjects

That's probably true - I have never learnt Actionscript, and although I started out with Javascript I dont have much experience with it.

ECMA Script is not an underlying Language merely a specification for languages to comply to

From the link you gave that appears to be inaccurate - ECMA Script is indeed a scripting/programming language, but Actionscript and Javascript are compatible with it.

[cyberlew15]

there is no ecma script interpreter go to http://www.ecma-international.org/memento/index.html and look for a download
oh have you only found information on standards. if the company that was paid to build the standard does not offer an ecma scripting module then it is not a language. I have e-mailed them so far with no answer I think if you read the original link ECMA was the specification for the old Jscript and Javascript that they were paid to write so that the wo technologies would be more closely integrated. if you strongly disagree with what I am saying post me a link to a page using an ecma script.

Such differences dont really count here - all compiled languages are interpreted at some level.

at some level all languages are interpreted eh what about machine code elmutt. I'm sure this is all because I made a post here and you just want to annoy me with your word games it cannot be a serious argument because you are wrong it is in writing I swear you must be one of those nutters that reads spot had a ball and expects it to have levels

[thorpe]

the ecma scripting language itself does not provide (nor need to) the environment in which it needs to run. that is up to the host to supply.

if your here to pick arguments, you might want to read up on the subject itself. just as you where wrong about VB, C and basic being object orientated languages, your points about the ecma scripting language are distorted.

[cyberlew15]

You may wish to do a little reading yourself as ECMA Script is a standard not an implementation. I have received an e-mail from it's creators confirming that there is not and never will be an ECMA Script parser sanctioned by them. they went on to write just what i have been saying that it is a standard. It is quite annoying that lots of people are continuing this argument I only wanted to do a one off post to educate some people but it seems they are ignoring this. I resent the inference that I am simply starting arguments. You would'nt moan so much if I supported good advice that you give but yet at the slightest hint of criticism you seem to blow up. Weedpacket has obviously read the original link and followed that links suggested reading and because weedpacket is able to take constructive criticism weedpacket will grow as a developer you guys seem to be the ones starting arguments Thorpe and Laserlight. How amazing that even though the evidence is staring you both in the face you refuse to admit defeat. Also seeing as this is a thread designed to help others learn about OOP i think you should voice your inadequacies elsewhere.

[thorpe]

i have read the document here several years ago, and i again briefly read the overview tonight. if the email is worded in the way you describe then there documentation is contradictive.

[cyberlew15]

Thorpe To the point in your last post I must concede that ECMA Script is infact a language in it's own right. although I doubt it's sucess and still strongly disagree that it is comparable to javascript or actionscript. Also others may wish to read the pdf file because it does clear up this whole issue JScript and JavaScript were the projenitors for ECMA Script and ECMA Script was apparently some failed project that worked with W3C as far as I know the language as a standalone or addon to a web server / browser does not exist anymore. Having Said this it still means ECMA Script is as dissimilar in syntax and functionality to all of the languages previously mentioned. I think now that JavaScript and ECMA Scripts other competitors are more popular it has just fallen into a standard for web scripting languages to comply to. Really it just has some similar features to JavaScript etc but is as dissimilar as two different websites

[ATS16805]

cyberlew15 wrote:

How amazing that even though the evidence is staring you both in the face you refuse to admit defeat.

wow. i realize that all involved in this debate have strong feelings for their own viewpoints, however, i viewed this entire thread as commentary on the issue of OOP. i do not understand how commentary can be "defeated", although i realize more than commentary has now arisen because of the debate which has ensued.

i am not learning much about OOP from this debate, and at this point it has become not much fun to add aditional commentary. this is not to say that i do not greatly appreciate that you all have so extensively entertained this thread.

[Elizabeth]

cyberlew15 wrote:

Also others may wish to read the pdf file because it does clear up this whole issue JScript and JavaScript were the projenitors for ECMA Script and ECMA Script was apparently some failed project that worked with W3C as far as I know the language as a standalone or addon to a web server / browser does not exist anymore.

<-- still trying to read Cyberlew's run-on sentences.

(Relax, I'm only kidding) 🙂

[Weedpacket]

Livescript was developed by Netscape, and became Javascript in collaboration with Sun. To get it adopted as a standard they approached the W3C and suggested that that organisation might want to adopt the role. W3C said no thanks, but ECMA did accept.

Javascript 1.5 complies with the language described in ECMA-262 3rd.ed. (Mozilla also adds parts of ECMA-357 and 262 4th.ed. Actionscript2 also has a few bits that were in draft versions of 262, but haven't been adopted for the third edition. In both cases, however, these are additions, and may be considered part of the next paragraph.) Strictly speaking, only Sun is allowed to use the name Javascript™.

Both languages have a lot of additional functionality that comes from the hosting environment: this is part of the intention of ECMAscript - rather than standardise the environment that people had to work in, which would limit its potential utility. But MyConstructor.prototype.proto.value = 5; still means the same thing in all of them.

(Incidentally, regarding

cyberlew15 wrote:

Weedpacket has obviously read the original link and followed that links suggested reading

I have usage logs that tell me that the last time I looked at my local copy of ECMA-262 was in October 2003.

And while I'm in these parentheses,

absolute rubbish actionscript utilises a much more advanced control of it's DOM(the flash DOM)

Oh, so there is a difference in the interfaces provided by the environment? Gee, why didn't I mention anything about that?)

ATS16805 wrote:

am not learning much about OOP from this debate

Are there any aspects in particular you'd like more detail on? OOP on its own is a big cloudy thing and tends to fade off gradually rather than there being any sharp boundaries between "OOP/Not OOP". I guess one reason is how lately languages themselves have been getting broken down into common syntax architectures for developers to plug components of their own language into.

[laserlight]

if the company that was paid to build the standard does not offer an ecma scripting module then it is not a language.

Not really, it would still be a programming language, but a standard model for other conforming implementations. I'm just relying on your link, so if the info provided there is inaccurate, then my knowledge must be inacccurate. But then you've conceded this point, so I suppose the info in the link you provided is accurate.

at some level all languages are interpreted eh what about machine code

Machine code is interpreted by the machine, duh. The point here is that using compiled/interpreted as a criteria for distinguishing programming languages often is not very useful. It is often more useful to consider the concepts that come with the programming language, e.g. OOP.

Weedpacket has obviously read the original link and followed that links suggested reading and because weedpacket is able to take constructive criticism weedpacket will grow as a developer .

Um, the only thing I pointed out (originally) was that ECMA script, based on the info provided in your link, is a programming/scripting language (as what Weedpacket wrote).

you guys seem to be the ones starting arguments Thorpe and Laserlight

You wrote that "I resent the inference that I am simply starting arguments", and now you say this. Dont you think that I (and Thorpe) will also resent the direct statement that we are simply starting arguments?

How amazing that even though the evidence is staring you both in the face you refuse to admit defeat.

You wrote "I must concede that ECMA Script is infact a language in it's own right". Clearly your original stand was wrong - but it is not that I'm trying to win an argument (I dont have any), I'm trying to clarify a point since what you wrote and what you linked to seemed to say different things.

Also seeing as this is a thread designed to help others learn about OOP i think you should voice your inadequacies elsewhere.

Um, may I suggest that you keep ad hominem attacks away?

[ATS16805]

Weedpacket wrote:

Are there any aspects in particular you'd like more detail on?

no, not at all. you have all quite extensively satisfied my curiosity. when i said "not learning much", i was referencing the particular debate which seemed to be going on a while back.

i can't say that i've never addressed other users publicly w/ comments which would probably best be left for private debate-- for the sake of the public's reading. i suppose it boils down to pride and saving face. hey, we've probably all done it. whatever.

i guess the reason for my statement which you quoted was my own little way of saying that i would rather hear more about examples or explanations, rather than that kind of fine hair-splitting. it's all way over my head. i should just keep my mouth shut, really. i have learned a great deal from this thread. very much that i would never have known (stuff you wrote weedpacket, of the origins of javascript, etc, and many other things that other contributers wrote... printelectric, etc... and others). i'm fortunate to have been involved if even from a reader's standpoint. i wish i could contribute to the discussion, but all i can say is "wow", and "i didn't know that... could you tell me more?" but, there is valuable information here-- and considering the OOP discussion the context of this thread, one who wishes to further investigate OOP would be fortunate to read all that is here.

one last bit, and then i'll be finished-- i think what i was really trying to say is that i didn't want to see a good thread of valuable info end on a sour note. i hate to bear witness to the counter-productive effect of implicit name-calling, and back-and forth jabs at each other. it's almost embarrassing to read.

none of what i'm saying is inteded to be accusatory either. we all have our moments-- especially when strong convictions are involved.

thanks again. cheers!

[Weedpacket]

Examples! Yes!

The most visible example of OOP really flying is in graphical user interfaces. Each widget is an object, many of which are made up of several others; a Window may have a Titlebar, a MenuBar (with Menus that have MenuItems), Scrollbars (which have a track, a slider, and a couple of buttons)..... Underneath there'd be a generic "Button" object, from which more specialised buttons would be created ("Close buttons", "Scrollbar Buttons", and whatsyourfancy). So the principle is that all the code that makes any sort of button gets written once and that becomes the Button class. All the code that distinguishes a Close Button from an ordinary button would be written once and that becomes the CloseButton class. Then once you've got the classes you can use them to crank out CloseButtons galore.

Ultimately (and ideally from the paradigm's point of view), everything is an object. Not only is a Button an object, but its appearance as well - if you make it a separate entity from the button itself you can then have Themes.

Another example is the Javascript DOM. An HTML (or XML) document is an object. Its header element is an object; ditto its title element, ditto every element. This is the DOM representation of an HTML document. Javascript has an interface to manipulate this representation: do that in a browser displaying the document, and it's redrawn to reflect the changes. Every single aspect of the page can be rewritten ad lib. An entire page could be built from scratch, or totally replaced, just by messing around with its DOM representation. No doubt ActionScript gives just as much control over Flash movies.

Firefox's entire front end is written in this wise: a dialect of XML to describe the layout, CSS to describe its appearance, and Javascript to define its functionality. I shudder to think of the work that would be involved to achieve such a division of labour if you couldn't have a distinct "thing" you could work with in isolation - that you could uniquely identify at any time and to which you could attach behaviour, give an appearance to, and then position.

Of course, in the end, it's all ones and zeros. The OO paradigm could be used in literally any programming language (and a good thing too, otherwise it couldn't be translated into machine code). It's just that some languages make it easier than others: from those where using it makes for the simplest and easiest-to-understand programs, all the way to those where it's easier to use it to write a compiler to implement a more OO-friendly language.

[halojoy]

halojoy wrote:

thanks
for your PM
ATS1867
please read my answer

sorry this is out of topic :bemused:

I didnt get your reaction to this ATS1867
( issnt it a drag with people too lazy to read more than last post in a thread??? )

halojoy sorry, for repeating himself and for complaining
please forgive me - somtimes see no other way ..

🙂

[dartcol]

I've put this off for way too long so I'm going to have another stab at learning about OOP. I've had at least 5 people explain it to me and looked at a number of examples but for some reason seem to have a complete blank spot here. Your example really helps and gives me some encouragement to have another go.

Underneath there'd be a generic "Button" object, from which more specialised buttons would be created ("Close buttons", "Scrollbar Buttons", and whatsyourfancy). So the principle is that all the code that makes any sort of button gets written once and that becomes the Button class. All the code that distinguishes a Close Button from an ordinary button would be written once and that becomes the CloseButton class. Then once you've got the classes you can use them to crank out CloseButtons galore.

Does this mean you call the Button class first and then the CloseButton class? How does one inherit the values of the other? How would they sit together (if that is what they do)? How would they be called by a script?

[vaaaska]

Might be the most fascinating thread ever. I struggle understanding the bigger picture with OOP (in relation to PHP for my purposes). I certainly get it, can do it, but for the sake of developing a web-application with it I just can't see it...except with quite alot of bloated stuff. More examples are helpful to myself as well...merci beacoup.

I believe that PHP5 does have a way of calling up only the pieces that it needs (but I can 't remember what the book said right now).

Somebody really said this?

Weedpacket has obviously read the original link and followed that links suggested reading and because weedpacket is able to take constructive criticism weedpacket will grow as a developer.

Congratulations Weedpacket! 😉

[Shrike]

The idea is that Button would define all of the basic properties of a button, and CloseButton would extend Button with the extra properties of a close button. On instantiating a CloseButton object it would contain the properties of a Button and a CloseButton.

Below there are 3 classes defined. Button is a 'base' class - it defines some basic properties for a button, and importantly, is not derived from any other classes. The 2 other classes are derived from Button (using the 'extends' keyword) and provide some specific functionality. This relationship is known as inheritance. It is also sometimes described as the 'is_a' relationship. CloseButton is_a Button because it's derived from the Button base class. This can be useful in determining what methods an object has.

Every CloseButton or SubmitButton created contains a set of the properties defined in Button, and they can be changed independently. This is known as encapsulation.

class Button
{
  var $label;
  var $shape;
  var $color;

  function button( $label, $shape, $color )
  {
    $this->label = $label;
    $this->shape = $shape;
    $this->color = $color;
  }
}
// Note: ommitting the constructor method in a derived class causes the parent constructor to be called.
class CloseButton extends Button
{
  function push()
  {
    $window->close();
  }
}
class SubmitButton extends Button
{
  function push()
  {
    $window->submit();
  }
}
$buttons[] = new CloseButton( 'Close', 'Square', 'Green' );
$buttons[] = new SubmitButton( 'Submit', 'Rectangle', 'Red' );

You might also note that the 2 derived classes both have a push() method. This is known as polymorphism. The idea behind this is that as long as classes share the same API (their methods) they can be treated in exactly the same way, even though they do different things. Thus we can say:

foreach( $buttons as $button )
{
  $button->push();
}

I really think newcomers should tackle these 3 principles first because they are the backbone of object oriented design.

inheritance encapsulation polymorphism

Phew turned out to be a bit of an essay 😉 Hope it helps some.

[Shrike]

vaaaska wrote:

Somebody really said this?

Weedpacket has obviously read the original link and followed that links suggested reading and because weedpacket is able to take constructive criticism weedpacket will grow as a developer.

Congratulations Weedpacket! 😉

Time to cut back on the fast food lunches WP 😉