Casting Objects Within Class?

I'm not sure how to ask for what I want, so I can't find it on Google.

I'll explain.....

I have a class 'hanging' with a constructor:

class hanging{
function hanging(){
}

}

//and a class curtain
class curtain extends hanging{
function curtain(){
}

}

//and a blind
class blind extends hanging{
function blind(){
}

}

In the hanging constructor the object gets database info part of which
has an ID number for its type, so I want the constructor to have
something like....

function hanging(){
//blah blah
if ( type_ID is curtain ){
$this-> is a curtain object
}
//etc etc

}

But I don't know how. Any help would be appreciated.

Thanks

Pete

Re: Casting Objects Within Class?

petethebloke@googlemail.com wrote:
> I'm not sure how to ask for what I want, so I can't find it on Google.
>
> I'll explain.....
>
> I have a class 'hanging' with a constructor:
>
> class hanging{
> function hanging(){
> }
>
> }
>
> //and a class curtain
> class curtain extends hanging{
> function curtain(){
> }
>
> }
>
> //and a blind
> class blind extends hanging{
> function blind(){
> }
>
> }
>
> In the hanging constructor the object gets database info part of which
> has an ID number for its type, so I want the constructor to have
> something like....
>
> function hanging(){
> //blah blah
> if ( type_ID is curtain ){
> $this-> is a curtain object
> }
> //etc etc
>
> }
>
> But I don't know how. Any help would be appreciated.
>
> Thanks
>
> Pete
>

Pete,

You can't that way. When you create the class, you need to know what
type it is then - 'curtain' or 'blind', for instance. But once you're
in the constructor, you already have the object created.

You could create a static method in the hanging class which will
retrieve the information from the database, then depending on the type,
create the correct object and return its address. This isn't an ideal
solution because if you add 'tapestry' as a derived class of hanging,
you need to go back and modify the static function. But it works.

But I also have to ask - do you really need all three classes? What are
the differences between 'blind' and 'curtain'? Could they actually be
handled by a single class?

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

Re: Casting Objects Within Class?

On 3 Oct, 12:55, Jerry Stuckle wrote:
> petethebl...@googlemail.com wrote:
> > I'm not sure how to ask for what I want, so I can't find it on Google.
>
> > I'll explain.....
>
> > I have a class 'hanging' with a constructor:
>
> > class hanging{
> > function hanging(){
> > }
>
> > }
>
> > //and a class curtain
> > class curtain extends hanging{
> > function curtain(){
> > }
>
> > }
>
> > //and a blind
> > class blind extends hanging{
> > function blind(){
> > }
>
> > }
>
> > In the hanging constructor the object gets database info part of which
> > has an ID number for its type, so I want the constructor to have
> > something like....
>
> > function hanging(){
> > //blah blah
> > if ( type_ID is curtain ){
> > $this-> is a curtain object
> > }
> > //etc etc
>
> > }
>
> > But I don't know how. Any help would be appreciated.
>
> > Thanks
>
> > Pete
>
> Pete,
>
> You can't that way. When you create the class, you need to know what
> type it is then - 'curtain' or 'blind', for instance. But once you're
> in the constructor, you already have the object created.
>
> You could create a static method in the hanging class which will
> retrieve the information from the database, then depending on the type,
> create the correct object and return its address. This isn't an ideal
> solution because if you add 'tapestry' as a derived class of hanging,
> you need to go back and modify the static function. But it works.
>
> But I also have to ask - do you really need all three classes? What are
> the differences between 'blind' and 'curtain'? Could they actually be
> handled by a single class?
>
> --
> ==================
> Remove the "x" from my email address
> Jerry Stuckle
> JDS Computer Training Corp.
> jstuck...@attglobal.net
> ==================

Thanks for that Jerry.
I was trying to keep things simple (!).
At the moment I have 'design' and it does everything, but it has 30
odd methods
and I wanted to see if I could make things easier to manage. The idea
was to have
inheriting classes 'cushion', 'blind', 'pelmet', 'curtain' and so on
(it's a soft
furnishings site) where functions relevant only to cushions (or
whatever) would be
in the child class.

The reason I need to call design without knowing its type is that it
has to speak up
for itself in the shopping basket page.

Mind you.... it works at the moment, so maybe I'm only making grief
for myself.

Thanks again.

Pete

Re: Casting Objects Within Class?

petethebloke@googlemail.com wrote:
> On 3 Oct, 12:55, Jerry Stuckle wrote:
>> petethebl...@googlemail.com wrote:
>>> I'm not sure how to ask for what I want, so I can't find it on Google.
>>> I'll explain.....
>>> I have a class 'hanging' with a constructor:
>>> class hanging{
>>> function hanging(){
>>> }
>>> }
>>> //and a class curtain
>>> class curtain extends hanging{
>>> function curtain(){
>>> }
>>> }
>>> //and a blind
>>> class blind extends hanging{
>>> function blind(){
>>> }
>>> }
>>> In the hanging constructor the object gets database info part of which
>>> has an ID number for its type, so I want the constructor to have
>>> something like....
>>> function hanging(){
>>> //blah blah
>>> if ( type_ID is curtain ){
>>> $this-> is a curtain object
>>> }
>>> //etc etc
>>> }
>>> But I don't know how. Any help would be appreciated.
>>> Thanks
>>> Pete
>> Pete,
>>
>> You can't that way. When you create the class, you need to know what
>> type it is then - 'curtain' or 'blind', for instance. But once you're
>> in the constructor, you already have the object created.
>>
>> You could create a static method in the hanging class which will
>> retrieve the information from the database, then depending on the type,
>> create the correct object and return its address. This isn't an ideal
>> solution because if you add 'tapestry' as a derived class of hanging,
>> you need to go back and modify the static function. But it works.
>>
>> But I also have to ask - do you really need all three classes? What are
>> the differences between 'blind' and 'curtain'? Could they actually be
>> handled by a single class?
>>
>> --
>> ==================
>> Remove the "x" from my email address
>> Jerry Stuckle
>> JDS Computer Training Corp.
>> jstuck...@attglobal.net
>> ==================
>
> Thanks for that Jerry.
> I was trying to keep things simple (!).

Yea, but it's not always that way, unfortunately.

> At the moment I have 'design' and it does everything, but it has 30
> odd methods
> and I wanted to see if I could make things easier to manage. The idea
> was to have
> inheriting classes 'cushion', 'blind', 'pelmet', 'curtain' and so on
> (it's a soft
> furnishings site) where functions relevant only to cushions (or
> whatever) would be
> in the child class.
>

OK, that's reasonable enough.

> The reason I need to call design without knowing its type is that it
> has to speak up
> for itself in the shopping basket page.
>
> Mind you.... it works at the moment, so maybe I'm only making grief
> for myself.
>
> Thanks again.
>
> Pete
>

I suspect everything's in a single class right now, and some methods are
applicable to one object while not another. This would be a great use
of inheritance.

What I might recommend is to use the static function idea in the
'hanging' class. Maybe pass it a database row id (or the contents of
the row, if you wish) and have it build the appropriate class from the data.

As I said - it's not perfectly clean, but if you want to use
inheritance, someone needs to know what the classes you're using are.
And keeping everything in this one function means you can easily add
more classes to the inheritance hierarchy later.


--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

Re: Casting Objects Within Class?

> > Thanks for that Jerry.
> > I was trying to keep things simple (!).
>
> Yea, but it's not always that way, unfortunately.
>
> > At the moment I have 'design' and it does everything, but it has 30
> > odd methods
> > and I wanted to see if I could make things easier to manage. The idea
> > was to have
> > inheriting classes 'cushion', 'blind', 'pelmet', 'curtain' and so on
> > (it's a soft
> > furnishings site) where functions relevant only to cushions (or
> > whatever) would be
> > in the child class.
>
> OK, that's reasonable enough.
>
> > The reason I need to call design without knowing its type is that it
> > has to speak up
> > for itself in the shopping basket page.
>
> > Mind you.... it works at the moment, so maybe I'm only making grief
> > for myself.
>
> > Thanks again.
>
> > Pete
>
> I suspect everything's in a single class right now, and some methods are
> applicable to one object while not another. This would be a great use
> of inheritance.
>
> What I might recommend is to use the static function idea in the
> 'hanging' class. Maybe pass it a database row id (or the contents of
> the row, if you wish) and have it build the appropriate class from the data.
>
> As I said - it's not perfectly clean, but if you want to use
> inheritance, someone needs to know what the classes you're using are.
> And keeping everything in this one function means you can easily add
> more classes to the inheritance hierarchy later.
>
> --
> ==================
> Remove the "x" from my email address
> Jerry Stuckle
> JDS Computer Training Corp.
> jstuck...@attglobal.net
> ==================

Pete,

I was wrestling with much the same issue recently with a form library
I'm developing. I wanted there to be a Form class which would be
responsible for managing all the elements in a webpage form and a
FormElement class which the add_element method of the Form class would
use to construct child object elements of specific form field types
(e.g. ElementTextInput, an extension of FormElement).

It doesn't involve a database, but I did want to validate element
types against a central array. For that I ended up using the idea
Jerry suggested here: a static method in the base element class (I may
move it to the form class before I'm finished) that can be called
statically to retrieve a valid list of element types:

function get_valid_types()
{
$V = array(); // return

// element families
$V['INPUT_TEXT'] = array('input_text', 'input_email', 'input_url',
'input_password');
$V['TEXTAREA'] = array('textarea');

// all elements
$V['TYPE'] = array_merge($V['INPUT_TEXT'],$V['TEXTAREA']);

return $V;
}

So if I add a new subclass (say, a radio-button menu class), I can
just update this method.

Like you, I originally was dreaming of something simpler and more
elegant for the library as a whole. The resulting code ended up being
more complicated and required an additional Factory class to make
everything work as transparently on the API end as I wished. But once
I got that sorted out, implementation is pretty simple:

$TestForm = new CeoForm($debug);
$TestForm->add_element($name='text_input', $type='input_text',
$label='input some text', $is_required=1, $maxlength=255,
$minlength=4);
$TestForm->add_element($name='email_input', $type='input_email',
$label='email address', $is_required=1);
$TestForm->add_element($name='url_input', $type='input_url',
$label='web address', $is_required=0);

if ( $TestForm->is_valid() )
{
// insert results in db or whatever...
}
else
{
$show_form = 1;
}

Anyway, your problem strikes me as the same basic problem. If
interested, you can view the source for this library here:

http://klenwell.googlecode.com/svn/trunk/PHP/ceo/php_ceo/ext /input/

Tom

Re: Casting Objects Within Class?

On 3 Oct, 17:49, klenwell wrote:
> > > Thanks for that Jerry.
> > > I was trying to keep things simple (!).
>
> > Yea, but it's not always that way, unfortunately.
>
> > > At the moment I have 'design' and it does everything, but it has 30
> > > odd methods
> > > and I wanted to see if I could make things easier to manage. The idea
> > > was to have
> > > inheriting classes 'cushion', 'blind', 'pelmet', 'curtain' and so on
> > > (it's a soft
> > > furnishings site) where functions relevant only to cushions (or
> > > whatever) would be
> > > in the child class.
>
> > OK, that's reasonable enough.
>
> > > The reason I need to call design without knowing its type is that it
> > > has to speak up
> > > for itself in the shopping basket page.
>
> > > Mind you.... it works at the moment, so maybe I'm only making grief
> > > for myself.
>
> > > Thanks again.
>
> > > Pete
>
> > I suspect everything's in a single class right now, and some methods are
> > applicable to one object while not another. This would be a great use
> > of inheritance.
>
> > What I might recommend is to use the static function idea in the
> > 'hanging' class. Maybe pass it a database row id (or the contents of
> > the row, if you wish) and have it build the appropriate class from the data.
>
> > As I said - it's not perfectly clean, but if you want to use
> > inheritance, someone needs to know what the classes you're using are.
> > And keeping everything in this one function means you can easily add
> > more classes to the inheritance hierarchy later.
>
> > --
> > ==================
> > Remove the "x" from my email address
> > Jerry Stuckle
> > JDS Computer Training Corp.
> > jstuck...@attglobal.net
> > ==================
>
> Pete,
>
> I was wrestling with much the same issue recently with a form library
> I'm developing. I wanted there to be a Form class which would be
> responsible for managing all the elements in a webpage form and a
> FormElement class which the add_element method of the Form class would
> use to construct child object elements of specific form field types
> (e.g. ElementTextInput, an extension of FormElement).
>
> It doesn't involve a database, but I did want to validate element
> types against a central array. For that I ended up using the idea
> Jerry suggested here: a static method in the base element class (I may
> move it to the form class before I'm finished) that can be called
> statically to retrieve a valid list of element types:
>
> function get_valid_types()
> {
> $V = array(); // return
>
> // element families
> $V['INPUT_TEXT'] = array('input_text', 'input_email', 'input_url',
> 'input_password');
> $V['TEXTAREA'] = array('textarea');
>
> // all elements
> $V['TYPE'] = array_merge($V['INPUT_TEXT'],$V['TEXTAREA']);
>
> return $V;
>
> }
>
> So if I add a new subclass (say, a radio-button menu class), I can
> just update this method.
>
> Like you, I originally was dreaming of something simpler and more
> elegant for the library as a whole. The resulting code ended up being
> more complicated and required an additional Factory class to make
> everything work as transparently on the API end as I wished. But once
> I got that sorted out, implementation is pretty simple:
>
> $TestForm = new CeoForm($debug);
> $TestForm->add_element($name='text_input', $type='input_text',
> $label='input some text', $is_required=1, $maxlength=255,
> $minlength=4);
> $TestForm->add_element($name='email_input', $type='input_email',
> $label='email address', $is_required=1);
> $TestForm->add_element($name='url_input', $type='input_url',
> $label='web address', $is_required=0);
>
> if ( $TestForm->is_valid() )
> {
> // insert results in db or whatever...}
>
> else
> {
> $show_form = 1;
>
> }
>
> Anyway, your problem strikes me as the same basic problem. If
> interested, you can view the source for this library here:
>
> http://klenwell.googlecode.com/svn/trunk/PHP/ceo/php_ceo/ext /input/
>
> Tom

Thanks Jerry. Thanks Tom.
I'm diving off somewhere else at the moment but I'll take a look at
that code when I get back.
I appreciate you both having a look at this for me.

Pete