Page 1 of 1

question with clases and include()

Posted: Wed Feb 12, 2003 8:24 pm
by carlosluis
hey guys i got a question, the thing is that i'm developing an on-line calendar, so i got two clases Calendar and User, they both extend from a general class called Tgenera. I'm also using sessions to have an User object trought out the site, Now there is a page where i have to include Calendar and User, because i want to instatiate a new Calendar object but I need to access info of the User object in the session variable.

And I get this error:

Fatal error: Cannot redeclare class tgeneral in G:\Obivio\virtualoffice\cgi-bin\clases\standard.php on line 12

if i comment one of the includes the page loads but i cant access one of the objects.

When i do this with C++ there is no problem because i have the #ifndef macros, so what should i use instead of include?? require(), require_once(), include_once() ?????

please help

Posted: Wed Feb 12, 2003 8:54 pm
by Stoker
include_once() will make sure one file can not be loaded twice, I am not sure if I got exactly what you had, you have Tgenera in some file, User in another and Calendar in a third? and it fails when loading the thrid file?

Tried putting them all in the same file?

One thing to be aware of is that PHP does not support multiple inheritance, you can only extend one level...

In general, OO in PHP is something added because some ppl wanted it, it is very inefficient and very incomplete as an OO implementation, if you try to use it as C++ and Java do natively you probably run into limits pretty fast, from a resource-use and effectiveness kind of view there isn't many other situations you can justify using OO with PHP, usuallu when building dynamical data structures and such..

clases and include()

Posted: Sat Feb 15, 2003 9:30 am
by carlosluis
hey stoker, well thanx for your feedback, i have finally resolved my problem using include_once().
by the way you'r absolutely rigth about OO with PHP, i really sucks, i got a real problem with this, because i'm used to the OO aproach, and i believe that for big projects it's best. But the implementation of OO in PHP, is no good, how come you can access the variables inside and object directly, the should implement a "private" clause, because they are violating the information packaging.
as much as i like PHP, because it's flexiblility and performance, i'm really dissapointed with this. Do you know any othe languaje, that would allow me a native OO aproach, the same way C++ o Java does??

Re: clases and include()

Posted: Sat Feb 15, 2003 4:23 pm
by BDKR
carlosluis wrote:hey stoker, well thanx for your feedback, i have finally resolved my problem using include_once().
by the way you'r absolutely rigth about OO with PHP, i really sucks, i got a real problem with this, because i'm used to the OO aproach, and i believe that for big projects it's best. But the implementation of OO in PHP, is no good, how come you can access the variables inside and object directly, the should implement a "private" clause, because they are violating the information packaging.
as much as i like PHP, because it's flexiblility and performance, i'm really dissapointed with this. Do you know any othe languaje, that would allow me a native OO aproach, the same way C++ o Java does??
Being that it's a scripting language, I'm not sure what difference it's going to make whether or not the vars or anything else can be declared private or not. If you can look at the source then decide "Hey, I want this var public!", then make it so by changing the source, what advantages are there in putting this in the php engine?

The truth of the matter is that a paradigm is put in place to help us. However, it only helps as long as we adhere to it's suggestions and rules. Are you saying (this is meant to be rhetorical, not a real question or a flame) that becuase you can look at source you are likely to bypass a class developers suggestions about it's usage and access vars in a way that wasn't designed? If that's the case, the problem is with you as the developer, not the language.

A question: How is php or the php engine "violating the information packaging"? It's a programmer that chooses to do this. Not the language. Personally, I say that if the langauge allows me to the flexibility of accessing a var directly, great! Is that a good idea? Depends on your situation. But would't you rather the option if it came down to tuning a critical section of code that may be a bottleneck. Getters and setters and other mechanisms for accessing vars in a class carry the overhead of method lookup. :evil:

In short, people say that PHP OO is garbage just becuase it doesn't follow the OO paradigm to the letter. The reality is that people want the language to force them into
good practices regardless of the fact that they can "just practice them" on thier own.

PHP OO is just fine and getting better all the time. :P

However, you may want to look at Python or Ruby if absolute OO purity is your thing.

Cheers,
BDKR

i'd like to have a choice

Posted: Sun Feb 16, 2003 1:38 pm
by carlosluis
I don't totally agree, because the language allows people to write stupid, crappy code, it pretty much lets you do anything you want, and at the same time it doesn't give a choice for some stuff, for example what happens if i want to have a private variable?? o if i need a private variable. What happens when i want to let other access the variables of a clases, but i want to control the access, so it can have the rigth format?? This tends to make code more error prone. I don't think thats good, even for a so callend "scripting language". I doesn't matter if you are scripting, the language should enforce a certain use, so the code is more readable, more powerful, more effective, ...(i could go on for pages). But i dont think php does this the rigth way. It's a shame, because i'm like the language, but i think i has to keep up with modern paradigm such as OO.

Posted: Sun Feb 16, 2003 4:55 pm
by Stoker
I agree to some point, I think that it is cool that OO-things was added to PHP, I don't think it is crappy, I just don't see PHP (at the moment) as a good base for writing applications that are best fit oo-structures..

When it comes to intra-application security, there is no question in my mind that Java is the only safe alternative :) As the popular phrase goes, "In C++ classes, your friends can touch your privates" (Lance W 1999).

Some other languages that are OO oriented are Ruby, Python and Delphi/Kylix (OO-Pascal)..

I hear you

Posted: Mon Feb 17, 2003 12:07 pm
by BDKR
I hear where you guys are coming from and I understand the arguments. I just don't feel that the inevitable slow down that would result as including some of these checks into the engine are worth the gain.

As I said before, the other side of this is developer responsibity. Does the developer use a given API correctly or not? If that developer doesn't, it's not the fault of the language. However, perhaps it's the fault of the language for allowing it. It just occurs to me that it someone is intelligent enough to write code, why would they be so stupid as to ignore an API or interface then get upset when something falls over?

I know, it happens all the time and things like private vars (and so on) can help with this. But if someone is determined to stay stuck-on-stupid, what do you do when they can just look at the source code and "un" declare a private "whatever" public? The engine won't be able to help you then!

Now if you're working with a team of developers and one of them pulls something stupid like this, he needs to be talked too correct? However, if you're going it alone and you do something stupid like this, no language construct or otherwise is going to help you.

So, I don't believe there is any gain in having the engine for a scripting language enforce coding practices at the paradigm level (or in other words, baby sit stupid developers). Especially if it costs in performance and the developer can (through good coding practices) negate the need.

While I don't support the use of OO in all circumstances, I don't feel that php's OO is terrible.

Cheers,
BDKR