php-general Digest 7 Oct 2007 20:20:54 -0000 Issue 5060
Topics (messages 262890 through 262897):
Re: Please recommend blog script
262890 by: Paul Scott
Re: Beginner Tutorials for using CLASSES in PHP4
262891 by: Tony Marston
262897 by: Robert Cummings
Re: Sending lots of emails - 2 choices - choose the best one
262892 by: Per Jessen
262893 by: Stut
Re: A two flavored post
262894 by: tedd
Moodle: Add field to user listing
262895 by: RalfGesellensetter
262896 by: Tom Friedhof
Administrivia:
To subscribe to the digest, e-mail:
[EMAIL PROTECTED]
To unsubscribe from the digest, e-mail:
[EMAIL PROTECTED]
To post to the list, e-mail:
[EMAIL PROTECTED]
----------------------------------------------------------------------
--- Begin Message ---
On Sun, 2007-10-07 at 09:35 +0200, Niels wrote:
> Basically I want to integrate articles into existing pages, something like
> <?php blog::getArticlesHTML($rule); ?>
> <?php blog::getUserCommentEditHTML($article); ?>
>
What you want is a blog that exposes it's functionality as an API
(MetaWebLog or ATOM). Most do that, including the Chisimba one (see
http://fsiu.uwc.ac.za as an example. Download at http://avoir.uwc.ac.za)
--Paul
All Email originating from UWC is covered by disclaimer
http://www.uwc.ac.za/portal/uwc2006/content/mail_disclaimer/index.htm
--- End Message ---
--- Begin Message ---
""Nathan Nobbe"" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> On 10/6/07, Robert Cummings <[EMAIL PROTECTED]> wrote:
>
>>
>> Tony is right here. Encapsulation is about hiding the details of the
>> implementation
>
>
> rob, here is tonys definition of encapsulation:
> Encapsulation is the act of placing data and the
> operations that perform on that data in the same class. The data does not
> have to be private at all.
> tony did not at any point say that encapsulation is about hiding
> implementation details.
> im the one who indicated encapsulation is about hiding implementation
> details.
>
> tonys definition is contrary to all the definitions i have pulled from
> books
> on object oriented programming (see last post).
> actually, its not contrary, but it is only part of the definition.
It is not PART of the deinition of encapsulation, it is THE definition of
encapsulation. making variables (or even methods for that matter) is an
optional addition. Data does not HAVE to be hidden to be encapsulated.
> encapsulation is infact about hiding implementation details; its about
> driving client code through a well defined interface, to get access to the
> behavior the class supplies.
> in order to implement this behavior there are often times variables *and*
> methods that client code should not have access to.
I repeat, hiding data is optional, not mandatory.
> i pointed out that classes that do not utilize ppp allow client code to
> become dependent upon their implementation.
This is a meaningless statement. ALL classes are dependent on their
implementation. The implementation is the code which is executed when a
method is called, not the data which is manipulated.
> because weve only been
> stressing the hiding of member variables (i guess thats what data hiding
> means) in this conversation i think we have glossed over the fact that it
> is
> also important to be able to hide certain member functions as well.
Hiding meber variables may be important to some people, but it is entirely
optional, not mandatory.
> this cannot be done in php4, and as i said can lead to systems where
> client
> code is made dependent upon the implementation of other classes, which
> leads
> to very delicate systems.
Hiding variables does not make code less delicate. Just suppose class A
calls a method on class B, but some dimwit code monkey removes (or renames)
that method? The result is broken code. Making a variable hidden *in itself*
does not guarantee unbroken code - that depends entirely on the expertise of
your programmers.
> you guys are not the only php4 advocates ive run into; it just so happens
> i
> have a good friend with a very strong php background who tells me
> practically the same thing, ppp isnt that big of a deal. i disagree, why,
> is it because ive had a classical education in oop,
So in other words it is important because you have been taught that it is
important. I was taught no such thing, therefore I have to disagree.
> because ive worked with
> a number of languages that dont allow you to create class members without
> specifying an access level?
The default access level in PHP 4 is "public". The fact that the options
"private" and "protected" are not available has absolutely no effect on the
resulting code.
> for those reasons and because ive had the
> misfortune of working in places that have tightly coupled code. im
> talking
> about hundreds of thousands of lines of madness. ppp could have saved
> these
> systems greatly.
PPP (Public/Private/Protected) on its own will not guarantee clean code.
That is dependent upon man other factors.
> Also, don't forget that abstraction, encapsulation, and information
>> hiding all have a price.
>>
>
> if youre referring to performance i think the price of not using these
> tools
> is also worth mention. namely code which is easily subject to tight
> coupling, which as i said leads to systems that are difficult to maintain
> and extend.
> personally i value maintainability and extensibility over performance, but
> thats merely a personal preference.
>
> (tony)
>> I strongly disagree. It *IS* possible to write perfectly adequate OO
> programs
>> using PHP 4. If you cannot then you have been taught some bad habits.
>
> and what exactly does adequate mean?
The definition of OOP is "programming which is oriented around objects, thus
taking advantage of Encapsulation, Polymorphism, and Inheritance to increase
code reuse and decrease code maintenance". It is possible to do this in PHP
4 without all the fancy add-ons which appeared in PHP 5. How do I know?
Because I have written an entire framework using objects in PHP 4, and the
result is high code reuse and low maintainence. There are no additional OO
features in PHP 5 which could deliver any measurable improvements.
> any oo php4 'program' is inherently
> weak for the reasons i have sighted, namely the implementation can be
> latched onto producing tightly coupled code.
Coupling is the degree of interaction between two modules. Low levels of
coupling tend to create code which is more reusable, whereas high levels of
coupling tend to create code which is less reusable. Coupling is therefore
directly related to reusability. Making all variables private does not *in
itself* make the code more reusable, therefore it does not make the code
more "coupled" or less "coupled".
> dont worry tony, i can construe some pretty decent php4 code myself; i
> wrote
> a date time package that ive ported to 3 projects including a conversion
> to
> php5 in one of those. the point is that the other developers i work with
> dont have a clue about object oriented concepts which in my experience
> constitutes the vast majority of php developers.
It also includes a lot of those who *think* they know abou OOP. There are
numerous dfferent opinions as to what OOP either is or is not, so it is
quite easy for a novice to be led up the wrong path.
> the even bigger point, on
> the topic of this thread is that php4 is out the door, so there is yet
> another possibly more important reason not to waste time learning oop
> studying php4.
>
> ive studied oop for years and worked with a number of oop languages; many
> of
> the bad habits i had at one point or another have been removed. guess
> what
> the first one was, not letting client code access member variables
> directly :)
So all your access is via getters and setters? Guess what, there is a school
of thought that says these are evil - take a look at
http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html
> if you dont mind brittle oop code, php4 will suffice. if you want to tap
> into real object oriented features, many of which i consider fundamental
> (such as ppp [to name just one]) go for php5.
There are no OO features n PHP 5 which will improve on what I have written
in PHP 4, so why waste time using them? Just because they are there? That's
a very poor argument.
> truthfully i still think
> there are some features missing; interface hierarchies being the main one,
WTF is an "interface hierarchy"? Is this something to do with multiple
inheritance?
--
Tony Marston
http://www.tonymarston.net
http://www.radicore.org
> perhaps well get lucky in php6...
>
> -nathan
>
--- End Message ---
--- Begin Message ---
On Sat, 2007-10-06 at 22:20 -0700, Nathan Nobbe wrote:
> On 10/6/07, Robert Cummings <[EMAIL PROTECTED]> wrote:
>
> >
> > Tony is right here. Encapsulation is about hiding the details of the
> > implementation
>
>
> rob, here is tonys definition of encapsulation:
> Encapsulation is the act of placing data and the
> operations that perform on that data in the same class. The data does not
> have to be private at all.
> tony did not at any point say that encapsulation is about hiding
> implementation details.
> im the one who indicated encapsulation is about hiding implementation
> details.
Yes but you also said it is about data hiding. That is not true. They
are related, but data hiding is not a requirement of encapsulation.
> tonys definition is contrary to all the definitions i have pulled from books
> on object oriented programming (see last post).
> actually, its not contrary, but it is only part of the definition.
>
> encapsulation is infact about hiding implementation details; its about
> driving client code through a well defined interface, to get access to the
> behavior the class supplies.
> in order to implement this behavior there are often times variables *and*
> methods that client code should not have access to.
Sure, but those variables don't need to be hidden. In fact, if the
purpose of the variable will never change then there's no need to hide
it. And if later down the road you must... refactor.
> i pointed out that classes that do not utilize ppp allow client code to
> become dependent upon their implementation. because weve only been
> stressing the hiding of member variables (i guess thats what data hiding
> means) in this conversation i think we have glossed over the fact that it is
> also important to be able to hide certain member functions as well.
>
> this cannot be done in php4, and as i said can lead to systems where client
> code is made dependent upon the implementation of other classes, which leads
> to very delicate systems.
This CAN be done in PHP4. It is common convention to precede your
variable with an underscore or more if it is intended to be private.
Either way, nothing replaces good documentation. A short comment by the
variable that says "PRIVATE" is usually sufficient to get the point
across. If someone then uses outside the class, well tough luck.
> you guys are not the only php4 advocates ive run into;
Don't confuse my stance on PHP4 and PHP5 as being an explicit advocate
of PHP4 over PHP5. PHP5 and beyond is where things are going and my code
is already ready. But I do not believe in blatantly throwing away
compatibility for the convenience of syntactic sugar.
> it just so happens i
> have a good friend with a very strong php background who tells me
> practically the same thing, ppp isnt that big of a deal.
It isn't.
> i disagree, why,
> is it because ive had a classical education in oop
What the heck is a classical education in OOP? Are you saying your old
and therefore smarter? Young and therefor smarter? WTF?
> , because ive worked with
> a number of languages that dont allow you to create class members without
> specifying an access level?
Many of us have done this. Your point?
> for those reasons and because ive had the
> misfortune of working in places that have tightly coupled code. im talking
> about hundreds of thousands of lines of madness. ppp could have saved these
> systems greatly.
Once again, just because someone writes bad programs doesn't make PPP
the superior choice. A shitty programmer faced with PPP will more than
likely declare all of their member variables as public and as such will
have gained nothing.
> Also, don't forget that abstraction, encapsulation, and information
> > hiding all have a price
>
> if youre referring to performance i think the price of not using these tools
> is also worth mention. namely code which is easily subject to tight
> coupling, which as i said leads to systems that are difficult to maintain
> and extend.
> personally i value maintainability and extensibility over performance, but
> thats merely a personal preference.
Tell that to an embedded systems programmer.
> (tony)
> > I strongly disagree. It *IS* possible to write perfectly adequate OO
> programs
> > using PHP 4. If you cannot then you have been taught some bad habits.
Hear hear.
> and what exactly does adequate mean? any oo php4 'program' is inherently
> weak for the reasons i have sighted, namely the implementation can be
I'm sur eyou meant "cited" above.
> latched onto producing tightly coupled code.
> dont worry tony, i can construe some pretty decent php4 code myself; i wrote
> a date time package that ive ported to 3 projects including a conversion to
> php5 in one of those. the point is that the other developers i work with
> dont have a clue about object oriented concepts which in my experience
> constitutes the vast majority of php developers. the even bigger point, on
> the topic of this thread is that php4 is out the door, so there is yet
> another possibly more important reason not to waste time learning oop
> studying php4.
Once again, if you suck at programming you suck at programming. Those
sucky programmers are probably going to declare all their member vars
public, aren't going to understand encapsulation, probably will have
terrible class hierarchies, etc. You can't make a good programmer by
holding their hand.
> ive studied oop for years and worked with a number of oop languages; many of
> the bad habits i had at one point or another have been removed. guess what
> the first one was, not letting client code access member variables directly
> :)
I've worked with many languages too. I found my code getting better
while using C. I learned to properly prefix function names, collect them
together in the same file, use structures instead of 20 parameter
functions, etc. Lessons are learned wherever you spend your time.
> if you dont mind brittle oop code, php4 will suffice. if you want to tap
> into real object oriented features, many of which i consider fundamental
> (such as ppp [to name just one]) go for php5. truthfully i still think
> there are some features missing; interface hierarchies being the main one,
> perhaps well get lucky in php6...
Nothing brittle at all about PHP4 code. I can completely screw up any
PHP5 code you send my way too.
Cheers,
Rob.
--
...........................................................
SwarmBuy.com - http://www.swarmbuy.com
Leveraging the buying power of the masses!
...........................................................
--- End Message ---
--- Begin Message ---
Martin Zvarík wrote:
> Hello--
> I want to send email to 100+ recipients. Two choices I thought of:
>
> 1) once call mail() and use BCC, but the negative of this method is
> that every recipient in BCC has header "To" same (so I used to put my
> email in here - not email of one of the recipients).
>
> 2) several calls to mail() function with each recipient's emal
I would be tempted to generate a shell-script with emails and sendmail
commands inline, then do exec() on that.
Something along these lines:
sendmail -oi -f <from> <to> <<XXXX
email
email
email
email
XXXX
sendmail -oi -f <from> <to> <<XXXX
email
email
email
email
XXXX
.
.
.
.
.
etc.
/Per Jessen, Zürich
--- End Message ---
--- Begin Message ---
Martin Zvarík wrote:
Hello--
I want to send email to 100+ recipients. Two choices I thought of:
1) once call mail() and use BCC, but the negative of this method is that
every recipient in BCC has header "To" same (so I used to put my email
in here - not email of one of the recipients).
2) several calls to mail() function with each recipient's emal
Why are you sending mail to 100+ recipients? Is it something you do
often? Is it always the same recipients? When are you sending them?
If it's a mailing list use mailing list software as Daevid suggested -
it's what it's for!
I would recommend avoiding the use of BCC from PHP.
-Stut
--
http://stut.net/
--- End Message ---
--- Begin Message ---
ALSO:
<a href="img.php?i=<?php echo($value);?>" onclick="window.location =
this.getAttribute( 'href' ) + '&s=' + s; return false;">
can be altered to be:
<a href="img.php?i=<?php echo($value);?>"
onclick="this.setAttribute(this.getAttribute( 'href') + '&s=' + s);">
What exactly do you need to do, anyways? Maybe there'll be some better
way to do this.
I'm sure there is a better way.
I was just trying to get a user's selection (in an CMS I'm
developing) without a refresh.
Something like this:
http://www.webbytedd.com/c/js-maintain-state/
But ultimately, I was faced with a trade-off.
1) I could use javascript with no refresh, but lose hover;
2) Or, I could use php and maintain hover, but be forced to accept refresh.
So, I went back to php and accomplished what I wanted with a *lot*
less code. My thinking, the user shouldn't object to a refresh while
editing.
Thanks for everyone's help.
Cheers,
tedd
Rob -- it now works with js turned off. :-)
--
-------
http://sperling.com http://ancientstones.com http://earthstones.com
--- End Message ---
--- Begin Message ---
Dear list,
is there any approach to patch any PHP files within moodle in order to
gain further columns for the user list?
Reference: http://docs.moodle.org/en/Browse_list_of_users
Objective: I wish to add a (sortable) user field in order to find users
by additional aspects.
Thanks
Ralf
--- End Message ---
--- Begin Message ---
You will probably get better luck in getting an answer to this question by
mailing the Moodle mailing list or forums.
On 10/7/07, RalfGesellensetter <[EMAIL PROTECTED]> wrote:
>
> Dear list,
>
> is there any approach to patch any PHP files within moodle in order to
> gain further columns for the user list?
>
> Reference: http://docs.moodle.org/en/Browse_list_of_users
>
> Objective: I wish to add a (sortable) user field in order to find users
> by additional aspects.
>
> Thanks
> Ralf
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--- End Message ---
