Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.php > #16964 > unrolled thread

Class 'Model' not found

Back to article view | Back to comp.lang.php

Contents

  Class 'Model' not found M desinger <info.nez@gmail.com> - 2016-08-21 07:35 -0700
    Re: Class 'Model' not found M desinger <info.nez@gmail.com> - 2016-08-21 07:36 -0700
    Re: Class 'Model' not found M desinger <info.nez@gmail.com> - 2016-08-21 07:43 -0700
      Re: Class 'Model' not found "J.O. Aho" <user@example.net> - 2016-08-21 18:08 +0200
        Re: Class 'Model' not found "Christoph M. Becker" <cmbecker69@arcor.de> - 2016-08-21 19:36 +0200
      Re: Class 'Model' not found Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-08-22 20:56 +0200
        Re: Class 'Model' not found Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-22 19:08 -0400
          Re: Class 'Model' not found Matthew Carter <m@ahungry.com> - 2016-08-23 01:23 -0400
            Re: Class 'Model' not found Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-23 08:07 -0400
              Re: Class 'Model' not found Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-08-27 14:26 +0200
                Re: Class 'Model' not found Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-27 10:13 -0400
                  Re: Class 'Model' not found Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-08-28 02:12 +0200
                    Re: Class 'Model' not found Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-27 20:32 -0400
                Re: Class 'Model' not found Matthew Carter <m@ahungry.com> - 2016-08-28 00:00 -0400
                  Re: Class 'Model' not found Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-28 08:40 -0400
                    Re: Class 'Model' not found Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-08-30 11:39 +0200
                      Re: Class 'Model' not found Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-30 07:41 -0400
                        Re: Class 'Model' not found Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-08-30 14:41 +0200
                          Re: Class 'Model' not found Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-30 09:02 -0400
                            Re: Class 'Model' not found Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-08-30 15:36 +0200
                              Re: Class 'Model' not found Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-30 10:39 -0400
                  Re: Class 'Model' not found Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-08-30 11:35 +0200
    Re: Class 'Model' not found M desinger <info.nez@gmail.com> - 2016-08-30 14:25 -0700
      Re: Class 'Model' not found Gregor Kofler <usenet@gregorkofler.com> - 2016-08-31 00:35 +0200
        Re: Class 'Model' not found M desinger <info.nez@gmail.com> - 2016-08-30 16:34 -0700
          Re: Class 'Model' not found Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-30 19:58 -0400

Page 1 of 2  [1] 2  Next page →

#16964 — Class 'Model' not found

Hello,please say how to fix error?

http://image.prntscr.com/image/7ed8056828874f37b2b62d2d9bc25d2d.png


12 line  - $class = new Model();

[toc] | [next] | [standalone]

#16965

svētdiena, 2016. gada 21. augusts 17:35:33 UTC+3, M desinger rakstīja:
> Hello,please say how to fix error?
> 
> http://image.prntscr.com/image/7ed8056828874f37b2b62d2d9bc25d2d.png
> 
> 
> 12 line  - $class = new Model();

[toc] | [prev] | [next] | [standalone]

#16966

Full code index.php



<?php



include './application/model/model.php';
include './application/config/system.php';
include './application/config/language.lv.php';




12 line ---> $class = new Model();

[toc] | [prev] | [next] | [standalone]

#16968

On 08/21/16 16:43, M desinger wrote:
> Full code index.php
> 
> 
> 
> <?php
> 
> 
> 
> include './application/model/model.php';
> include './application/config/system.php';
> include './application/config/language.lv.php';
> 
> 
> 
> 
> 12 line ---> $class = new Model();
> 

Are you sure it's called Model and nothing else like model?

-- 

 //Aho

[toc] | [prev] | [next] | [standalone]

#16969

On 21.08.2016 at 18:08, J.O. Aho wrote:

> On 08/21/16 16:43, M desinger wrote:
>
>> Full code index.php
>>
>> <?php
>>
>> include './application/model/model.php';
>> include './application/config/system.php';
>> include './application/config/language.lv.php';
>>
>> 12 line ---> $class = new Model();
> 
> Are you sure it's called Model and nothing else like model?

PHP is case-insensitive wrt. class names, so if the class would have
been defined as `model` the code would work nonetheless.  If the name is
something else altogether, that would cause issues, though.

Another possibility is that a file couldn't be included.  Check the
error_logs, or consider to use `require` instead of `include`.

-- 
Christoph M. Becker

[toc] | [prev] | [next] | [standalone]

#16970

M desinger wrote:

> Full code index.php
> 
> <?php
> 
> include './application/model/model.php';
> include './application/config/system.php';
> include './application/config/language.lv.php';
> 
> 12 line ---> $class = new Model();

The “include” should be “require_once”, so that you get a “Fatal error” if 
the inclusion fails, the error message telling you *why* “require_once” 
failed.  “require_once” instead of “require” includes those files only once, 
which avoids all sorts of problems.

In any case, the leading “./” is superfluous.

Finally, one uses namespaces and autoloading these days; *all* kinds of 
includes (include, include_once, require, and require_once) are deprecated 
for loading class files like model.php.  RTFM.

-- 
PointedEars
Zend Certified PHP Engineer 
<http://www.zend.com/en/yellow-pages/ZEND024953> | Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#16972

On 8/22/2016 2:56 PM, the troll Thomas 'Pointed Head' Lahn wrote:
> M desinger wrote:
> 
>> Full code index.php
>>
>> <?php
>>
>> include './application/model/model.php';
>> include './application/config/system.php';
>> include './application/config/language.lv.php';
>>
>> 12 line ---> $class = new Model();
> 
> The “include” should be “require_once”, so that you get a “Fatal error” if 
> the inclusion fails, the error message telling you *why* “require_once” 
> failed.  “require_once” instead of “require” includes those files only once, 
> which avoids all sorts of problems.
> 
> In any case, the leading “./” is superfluous.
> 
> Finally, one uses namespaces and autoloading these days; *all* kinds of 
> includes (include, include_once, require, and require_once) are deprecated 
> for loading class files like model.php.  RTFM.
> 

You've obviously not had the autoloading function pick up the wrong
version of a class.  But that's not surprising from you.  You have
repeatedly shown you have no concept of good coding techniques, and have
probably never had two classes of ANY name on your system.


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

[toc] | [prev] | [next] | [standalone]

#16974

Jerry Stuckle <jstucklex@attglobal.net> writes:

> On 8/22/2016 2:56 PM, the troll Thomas 'Pointed Head' Lahn wrote:
>> M desinger wrote:
>> 
>>> Full code index.php
>>>
>>> <?php
>>>
>>> include './application/model/model.php';
>>> include './application/config/system.php';
>>> include './application/config/language.lv.php';
>>>
>>> 12 line ---> $class = new Model();
>> 
>> The “include” should be “require_once”, so that you get a “Fatal error” if 
>> the inclusion fails, the error message telling you *why* “require_once” 
>> failed.  “require_once” instead of “require” includes those files only once, 
>> which avoids all sorts of problems.
>> 
>> In any case, the leading “./” is superfluous.
>> 
>> Finally, one uses namespaces and autoloading these days; *all* kinds of 
>> includes (include, include_once, require, and require_once) are deprecated 
>> for loading class files like model.php.  RTFM.
>> 
>
> You've obviously not had the autoloading function pick up the wrong
> version of a class.  But that's not surprising from you.  You have
> repeatedly shown you have no concept of good coding techniques, and have
> probably never had two classes of ANY name on your system.

Why would you have 2 identically named classes in the same namespace (if
different namespaces, alias them)?

If you're actually referring to 2 versions of the same class at
different points in time, why not a VCS?

-- 
Matthew Carter (m@ahungry.com)
http://ahungry.com

[toc] | [prev] | [next] | [standalone]

#16976

On 8/23/2016 1:23 AM, Matthew Carter wrote:
> Jerry Stuckle <jstucklex@attglobal.net> writes:
> 
>> On 8/22/2016 2:56 PM, the troll Thomas 'Pointed Head' Lahn wrote:
>>> M desinger wrote:
>>>
>>>> Full code index.php
>>>>
>>>> <?php
>>>>
>>>> include './application/model/model.php';
>>>> include './application/config/system.php';
>>>> include './application/config/language.lv.php';
>>>>
>>>> 12 line ---> $class = new Model();
>>>
>>> The “include” should be “require_once”, so that you get a “Fatal error” if 
>>> the inclusion fails, the error message telling you *why* “require_once” 
>>> failed.  “require_once” instead of “require” includes those files only once, 
>>> which avoids all sorts of problems.
>>>
>>> In any case, the leading “./” is superfluous.
>>>
>>> Finally, one uses namespaces and autoloading these days; *all* kinds of 
>>> includes (include, include_once, require, and require_once) are deprecated 
>>> for loading class files like model.php.  RTFM.
>>>
>>
>> You've obviously not had the autoloading function pick up the wrong
>> version of a class.  But that's not surprising from you.  You have
>> repeatedly shown you have no concept of good coding techniques, and have
>> probably never had two classes of ANY name on your system.
> 
> Why would you have 2 identically named classes in the same namespace (if
> different namespaces, alias them)?
> 
> If you're actually referring to 2 versions of the same class at
> different points in time, why not a VCS?
> 

Because you loaded two different packages, both with the same class
name.  Or you're running two different versions of software on the same
machine.

It's not at all uncommon when you're running multiple sites on one server.

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

[toc] | [prev] | [next] | [standalone]

#16980

Jerry Stuckle wrote:

> On 8/23/2016 1:23 AM, Matthew Carter wrote:
>> Jerry Stuckle <jstucklex@attglobal.net> writes:
>>> You've obviously not had the autoloading function pick up the wrong
>>> version of a class.  But that's not surprising from you.  You have
>>> repeatedly shown you have no concept of good coding techniques, and have
>>> probably never had two classes of ANY name on your system.
>> 
>> Why would you have 2 identically named classes in the same namespace (if
>> different namespaces, alias them)?
                         ^^^^^^^^^^ 
>> If you're actually referring to 2 versions of the same class at
>> different points in time, why not a VCS?
> 
> Because you loaded two different packages, both with the same class
> name.

You can have the same class name in the same namespace in two different 
*files*.

But you _can not_ have that in the same PHP program, not even as includes. 
It is not possible to redeclare classes, and you cannot undeclare/delete a 
class.  So it is irrelevant if you use an autoloader in that case.  For 
example,

  require_once 'Foo/Bar.php';
  require_once 'Baz/Bar.php';

where each Bar.php contains

  class Bar
  {
    // …
  }

results in “PHP Fatal error:  Cannot redeclare class Bar in … on line …”.  
No “use” statement can prevent that because the class has to be loaded 
*before* it can be aliased.  Which is why interoperable classes are declared 
in their own namespace these days (formerly, prefixes were used to avoid 
name collisions instead).

As for the same class in different namespaces, I have marked the important 
part in Matthew’s posting.  For further reference:

<http://php.net/manual/en/language.namespaces.importing.php>

IOW:

  /* or: use Foo\Bar\Baz */;
  use Foo\Bar\Baz as Bla;

  use Foo\Bar2\Baz as Blub;

Then there could be a “Foo/Bar/Baz.php” that contains
 
  namespace Foo\Bar;
 
  class Baz
  {
    // …
  }

and a “Foo/Bar2/Baz.php” that contains

  namespace Foo\Bar2;

  class Baz
  {
    // …
  }

and (with a suitable autoloader) you could just write

  /* or “new Baz()”, see above */
  new Bla();

  new Blub();

> Or you're running two different versions of software on the same machine.
> It's not at all uncommon when you're running multiple sites on one server.

If only you knew what you are talking about.

Different sites on the same machine, each using different versions of the 
same class, perhaps in the same namespace, would either use *different* 
autoloaders each (to avoid loading classes and their dependencies manually).  
This can be as simple as adapting the include_path per site, or as 
complicated as using different “require_once” statements (with different 
paths) to load the correct autoloader.

Or they would use one or more namespace-and-path-aware autoloaders.  It is 
possible to register *several* autoloaders, each only attempting to autoload 
the classes that are in its namespace.  Simple example:

  /* Library 1 code */

  function autoload_lib1 ($class)
  {
    echo "autoload_lib1: autoloading $class ...\n";
    if (strpos($class, "Lib1\\") !== 0)
    {
      trigger_error("DEBUG: autoload_lib1: autoloading of $class rejected: "
        . " Not in our namespace\n", E_USER_NOTICE);
      return;
    }

    /* Use include_once for the example only */
    include_once "lib1path" . DIRECTORY_SEPARATOR
      . str_replace("\\", DIRECTORY_SEPARATOR,
                    str_replace("Lib1\\", "", $class))
      . ".php";
  }

  spl_autoload_register("\\autoload_lib1", true);


  /* Library 2 code */

  function autoload_lib2 ($class)
  {
    echo "autoload_lib2: autoloading $class ...\n";
    if (strpos($class, "Lib2\\") !== 0)
    {
      trigger_error("DEBUG: autoload_lib1: autoloading of $class rejected: "
        . " Not in our namespace\n", E_USER_NOTICE);
      return;
    }

    /* Use include_once for the example only */
    include_once "lib2path" . DIRECTORY_SEPARATOR
      . str_replace("\\", DIRECTORY_SEPARATOR,
                    str_replace("Lib2\\", "", $class))
      . ".php";
  }

  spl_autoload_register("\\autoload_lib2", true);


  /* User code */

  new Lib1\Foo1();

[Usually it does not make sense to use two versions of the same library 
simultaneously because of different dependencies, and because the newer 
version can do more than the older one.  However, it is probably a good idea 
to always write an autoloader so that it does not attempt to autoload 
classes that are "out of its jurisdiction".]

It is also possible to have *one* autoloader that handles *several* 
namespaces and maps namespaces to paths correctly.  Simplest (as is, 
*unsafe*) case:

  function autoload_all ($class)
  {
    require_once str_replace("\\", DIRECTORY_SEPARATOR, $class) . ".php";
  }

  spl_autoload_register("\\autoload_all", true);

[Note that the autoloader can be in a namespace itself, which reduces the 
risk of namespace collisions for *its* declaration.  That also makes it 
easier to autoload only the classes "in the autoloader’s jurisdiction".]

IOW, the problems that you are presuming simply *do* *not* *exist*.
 
-- 
PointedEars
Zend Certified PHP Engineer 
<http://www.zend.com/en/yellow-pages/ZEND024953> | Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#16981

On 8/27/2016 8:26 AM, Thomas 'PointedEars' Lahn wrote:
> Jerry Stuckle wrote:
> 
>> On 8/23/2016 1:23 AM, Matthew Carter wrote:
>>> Jerry Stuckle <jstucklex@attglobal.net> writes:
>>>> You've obviously not had the autoloading function pick up the wrong
>>>> version of a class.  But that's not surprising from you.  You have
>>>> repeatedly shown you have no concept of good coding techniques, and have
>>>> probably never had two classes of ANY name on your system.
>>>
>>> Why would you have 2 identically named classes in the same namespace (if
>>> different namespaces, alias them)?
>                          ^^^^^^^^^^ 
>>> If you're actually referring to 2 versions of the same class at
>>> different points in time, why not a VCS?
>>
>> Because you loaded two different packages, both with the same class
>> name.
> 
> You can have the same class name in the same namespace in two different 
> *files*.
> 
> But you _can not_ have that in the same PHP program, not even as includes. 
> It is not possible to redeclare classes, and you cannot undeclare/delete a 
> class.  So it is irrelevant if you use an autoloader in that case.  For 
> example,
> 
>   require_once 'Foo/Bar.php';
>   require_once 'Baz/Bar.php';
> 
> where each Bar.php contains
> 
>   class Bar
>   {
>     // …
>   }
> 
> results in “PHP Fatal error:  Cannot redeclare class Bar in … on line …”.  
> No “use” statement can prevent that because the class has to be loaded 
> *before* it can be aliased.  Which is why interoperable classes are declared 
> in their own namespace these days (formerly, prefixes were used to avoid 
> name collisions instead).
> 
> As for the same class in different namespaces, I have marked the important 
> part in Matthew’s posting.  For further reference:
> 
> <http://php.net/manual/en/language.namespaces.importing.php>
> 
> IOW:
> 
>   /* or: use Foo\Bar\Baz */;
>   use Foo\Bar\Baz as Bla;
> 
>   use Foo\Bar2\Baz as Blub;
> 
> Then there could be a “Foo/Bar/Baz.php” that contains
>  
>   namespace Foo\Bar;
>  
>   class Baz
>   {
>     // …
>   }
> 
> and a “Foo/Bar2/Baz.php” that contains
> 
>   namespace Foo\Bar2;
> 
>   class Baz
>   {
>     // …
>   }
> 
> and (with a suitable autoloader) you could just write
> 
>   /* or “new Baz()”, see above */
>   new Bla();
> 
>   new Blub();
> 
>> Or you're running two different versions of software on the same machine.
>> It's not at all uncommon when you're running multiple sites on one server.
> 
> If only you knew what you are talking about.
> 

<snip bullshit that requires system-specific code that no one in their
right mind (which leaves out Pointed Head) would implement on a
production system>

Whoosh.  That's the sound of the discussion going right over your head.

But that's not unusual for you.

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

[toc] | [prev] | [next] | [standalone]

#16982

Jerry Stuckle wrote:

> <snip bullshit that requires system-specific code that no one in their
> right mind (which leaves out Pointed Head) would implement on a
> production system>

There is nothing system-specific in this *example* code.  In particular, 
DIRECTORY_SEPARATOR is _not_ system-specific.
 
> Whoosh.  That's the sound of the discussion going right over your head.

No, autoloading goes well over *your* head.  Smart people use autoloaders 
these days.  It is even in the PHP Coding Standards.  I strongly suggest
you either catch up or shut up.

-- 
PointedEars
Zend Certified PHP Engineer 
<http://www.zend.com/en/yellow-pages/ZEND024953> | Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#16983

On 8/27/2016 8:12 PM, Thomas 'Pointed Head' Lahn wrote:
> Jerry Stuckle wrote:
> 
>> <snip bullshit that requires system-specific code that no one in their
>> right mind (which leaves out Pointed Head) would implement on a
>> production system>
> 
> There is nothing system-specific in this *example* code.  In particular, 
> DIRECTORY_SEPARATOR is _not_ system-specific.
>  
>> Whoosh.  That's the sound of the discussion going right over your head.
> 
> No, autoloading goes well over *your* head.  Smart people use autoloaders 
> these days.  It is even in the PHP Coding Standards.  I strongly suggest
> you either catch up or shut up.
> 

Not at all.  But you have no idea what kind of problems it can cause.

As for the PHP coding standards - good programmers know just how bad
those "standards" are.  Did you help write them?  They look like your
work - they're that bad.

I strongly suggest you go back to ditch digging - if you ever figure out
which end of the shovel to use.  But I doubt you'll ever figure that
out, either.

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

[toc] | [prev] | [next] | [standalone]

#16984

Thomas 'PointedEars' Lahn <PointedEars@web.de> writes:

> Jerry Stuckle wrote:
>
>> On 8/23/2016 1:23 AM, Matthew Carter wrote:
>>> Jerry Stuckle <jstucklex@attglobal.net> writes:
>>>> You've obviously not had the autoloading function pick up the wrong
>>>> version of a class.  But that's not surprising from you.  You have
>>>> repeatedly shown you have no concept of good coding techniques, and have
>>>> probably never had two classes of ANY name on your system.
>>> 
>>> Why would you have 2 identically named classes in the same namespace (if
>>> different namespaces, alias them)?
>                          ^^^^^^^^^^ 
>>> If you're actually referring to 2 versions of the same class at
>>> different points in time, why not a VCS?
>> 
>> Because you loaded two different packages, both with the same class
>> name.
>
> You can have the same class name in the same namespace in two different 
> *files*.
>
> But you _can not_ have that in the same PHP program, not even as includes. 
> It is not possible to redeclare classes, and you cannot undeclare/delete a 
> class.  So it is irrelevant if you use an autoloader in that case.  For 
> example,
>
>   require_once 'Foo/Bar.php';
>   require_once 'Baz/Bar.php';
>
> where each Bar.php contains
>
>   class Bar
>   {
>     // …
>   }
>
> results in “PHP Fatal error:  Cannot redeclare class Bar in … on line …”.  
> No “use” statement can prevent that because the class has to be loaded 
> *before* it can be aliased.  Which is why interoperable classes are declared 
> in their own namespace these days (formerly, prefixes were used to avoid 
> name collisions instead).
>
> As for the same class in different namespaces, I have marked the important 
> part in Matthew’s posting.  For further reference:
>
> <http://php.net/manual/en/language.namespaces.importing.php>
>
> IOW:
>
>   /* or: use Foo\Bar\Baz */;
>   use Foo\Bar\Baz as Bla;
>
>   use Foo\Bar2\Baz as Blub;
>
> Then there could be a “Foo/Bar/Baz.php” that contains
>  
>   namespace Foo\Bar;
>  
>   class Baz
>   {
>     // …
>   }
>
> and a “Foo/Bar2/Baz.php” that contains
>
>   namespace Foo\Bar2;
>
>   class Baz
>   {
>     // …
>   }
>
> and (with a suitable autoloader) you could just write
>
>   /* or “new Baz()”, see above */
>   new Bla();
>
>   new Blub();
>
>> Or you're running two different versions of software on the same machine.
>> It's not at all uncommon when you're running multiple sites on one server.
>
> If only you knew what you are talking about.
>
> Different sites on the same machine, each using different versions of the 
> same class, perhaps in the same namespace, would either use *different* 
> autoloaders each (to avoid loading classes and their dependencies manually).  
> This can be as simple as adapting the include_path per site, or as 
> complicated as using different “require_once” statements (with different 
> paths) to load the correct autoloader.
>
> Or they would use one or more namespace-and-path-aware autoloaders.  It is 
> possible to register *several* autoloaders, each only attempting to autoload 
> the classes that are in its namespace.  Simple example:
>
>   /* Library 1 code */
>
>   function autoload_lib1 ($class)
>   {
>     echo "autoload_lib1: autoloading $class ...\n";
>     if (strpos($class, "Lib1\\") !== 0)
>     {
>       trigger_error("DEBUG: autoload_lib1: autoloading of $class rejected: "
>         . " Not in our namespace\n", E_USER_NOTICE);
>       return;
>     }
>
>     /* Use include_once for the example only */
>     include_once "lib1path" . DIRECTORY_SEPARATOR
>       . str_replace("\\", DIRECTORY_SEPARATOR,
>                     str_replace("Lib1\\", "", $class))
>       . ".php";
>   }
>
>   spl_autoload_register("\\autoload_lib1", true);
>
>
>   /* Library 2 code */
>
>   function autoload_lib2 ($class)
>   {
>     echo "autoload_lib2: autoloading $class ...\n";
>     if (strpos($class, "Lib2\\") !== 0)
>     {
>       trigger_error("DEBUG: autoload_lib1: autoloading of $class rejected: "
>         . " Not in our namespace\n", E_USER_NOTICE);
>       return;
>     }
>
>     /* Use include_once for the example only */
>     include_once "lib2path" . DIRECTORY_SEPARATOR
>       . str_replace("\\", DIRECTORY_SEPARATOR,
>                     str_replace("Lib2\\", "", $class))
>       . ".php";
>   }
>
>   spl_autoload_register("\\autoload_lib2", true);
>
>
>   /* User code */
>
>   new Lib1\Foo1();
>
> [Usually it does not make sense to use two versions of the same library 
> simultaneously because of different dependencies, and because the newer 
> version can do more than the older one.  However, it is probably a good idea 
> to always write an autoloader so that it does not attempt to autoload 
> classes that are "out of its jurisdiction".]
>
> It is also possible to have *one* autoloader that handles *several* 
> namespaces and maps namespaces to paths correctly.  Simplest (as is, 
> *unsafe*) case:
>
>   function autoload_all ($class)
>   {
>     require_once str_replace("\\", DIRECTORY_SEPARATOR, $class) . ".php";
>   }
>
>   spl_autoload_register("\\autoload_all", true);
>
> [Note that the autoloader can be in a namespace itself, which reduces the 
> risk of namespace collisions for *its* declaration.  That also makes it 
> easier to autoload only the classes "in the autoloader’s jurisdiction".]
>
> IOW, the problems that you are presuming simply *do* *not* *exist*.

Great explanation, a wonderful reference for anyone needing to
understand these topics better.

-- 
Matthew Carter (m@ahungry.com)
http://ahungry.com

[toc] | [prev] | [next] | [standalone]

#16985

On 8/28/2016 12:00 AM, Matthew Carter wrote:
> Thomas 'PointedEars' Lahn <PointedEars@web.de> writes:
> 
>> Jerry Stuckle wrote:
>>
>>> On 8/23/2016 1:23 AM, Matthew Carter wrote:
>>>> Jerry Stuckle <jstucklex@attglobal.net> writes:
>>>>> You've obviously not had the autoloading function pick up the wrong
>>>>> version of a class.  But that's not surprising from you.  You have
>>>>> repeatedly shown you have no concept of good coding techniques, and have
>>>>> probably never had two classes of ANY name on your system.
>>>>
>>>> Why would you have 2 identically named classes in the same namespace (if
>>>> different namespaces, alias them)?
>>                          ^^^^^^^^^^ 
>>>> If you're actually referring to 2 versions of the same class at
>>>> different points in time, why not a VCS?
>>>
>>> Because you loaded two different packages, both with the same class
>>> name.
>>
>> You can have the same class name in the same namespace in two different 
>> *files*.
>>
>> But you _can not_ have that in the same PHP program, not even as includes. 
>> It is not possible to redeclare classes, and you cannot undeclare/delete a 
>> class.  So it is irrelevant if you use an autoloader in that case.  For 
>> example,
>>
>>   require_once 'Foo/Bar.php';
>>   require_once 'Baz/Bar.php';
>>
>> where each Bar.php contains
>>
>>   class Bar
>>   {
>>     // …
>>   }
>>
>> results in “PHP Fatal error:  Cannot redeclare class Bar in … on line …”.  
>> No “use” statement can prevent that because the class has to be loaded 
>> *before* it can be aliased.  Which is why interoperable classes are declared 
>> in their own namespace these days (formerly, prefixes were used to avoid 
>> name collisions instead).
>>
>> As for the same class in different namespaces, I have marked the important 
>> part in Matthew’s posting.  For further reference:
>>
>> <http://php.net/manual/en/language.namespaces.importing.php>
>>
>> IOW:
>>
>>   /* or: use Foo\Bar\Baz */;
>>   use Foo\Bar\Baz as Bla;
>>
>>   use Foo\Bar2\Baz as Blub;
>>
>> Then there could be a “Foo/Bar/Baz.php” that contains
>>  
>>   namespace Foo\Bar;
>>  
>>   class Baz
>>   {
>>     // …
>>   }
>>
>> and a “Foo/Bar2/Baz.php” that contains
>>
>>   namespace Foo\Bar2;
>>
>>   class Baz
>>   {
>>     // …
>>   }
>>
>> and (with a suitable autoloader) you could just write
>>
>>   /* or “new Baz()”, see above */
>>   new Bla();
>>
>>   new Blub();
>>
>>> Or you're running two different versions of software on the same machine.
>>> It's not at all uncommon when you're running multiple sites on one server.
>>
>> If only you knew what you are talking about.
>>
>> Different sites on the same machine, each using different versions of the 
>> same class, perhaps in the same namespace, would either use *different* 
>> autoloaders each (to avoid loading classes and their dependencies manually).  
>> This can be as simple as adapting the include_path per site, or as 
>> complicated as using different “require_once” statements (with different 
>> paths) to load the correct autoloader.
>>
>> Or they would use one or more namespace-and-path-aware autoloaders.  It is 
>> possible to register *several* autoloaders, each only attempting to autoload 
>> the classes that are in its namespace.  Simple example:
>>
>>   /* Library 1 code */
>>
>>   function autoload_lib1 ($class)
>>   {
>>     echo "autoload_lib1: autoloading $class ...\n";
>>     if (strpos($class, "Lib1\\") !== 0)
>>     {
>>       trigger_error("DEBUG: autoload_lib1: autoloading of $class rejected: "
>>         . " Not in our namespace\n", E_USER_NOTICE);
>>       return;
>>     }
>>
>>     /* Use include_once for the example only */
>>     include_once "lib1path" . DIRECTORY_SEPARATOR
>>       . str_replace("\\", DIRECTORY_SEPARATOR,
>>                     str_replace("Lib1\\", "", $class))
>>       . ".php";
>>   }
>>
>>   spl_autoload_register("\\autoload_lib1", true);
>>
>>
>>   /* Library 2 code */
>>
>>   function autoload_lib2 ($class)
>>   {
>>     echo "autoload_lib2: autoloading $class ...\n";
>>     if (strpos($class, "Lib2\\") !== 0)
>>     {
>>       trigger_error("DEBUG: autoload_lib1: autoloading of $class rejected: "
>>         . " Not in our namespace\n", E_USER_NOTICE);
>>       return;
>>     }
>>
>>     /* Use include_once for the example only */
>>     include_once "lib2path" . DIRECTORY_SEPARATOR
>>       . str_replace("\\", DIRECTORY_SEPARATOR,
>>                     str_replace("Lib2\\", "", $class))
>>       . ".php";
>>   }
>>
>>   spl_autoload_register("\\autoload_lib2", true);
>>
>>
>>   /* User code */
>>
>>   new Lib1\Foo1();
>>
>> [Usually it does not make sense to use two versions of the same library 
>> simultaneously because of different dependencies, and because the newer 
>> version can do more than the older one.  However, it is probably a good idea 
>> to always write an autoloader so that it does not attempt to autoload 
>> classes that are "out of its jurisdiction".]
>>
>> It is also possible to have *one* autoloader that handles *several* 
>> namespaces and maps namespaces to paths correctly.  Simplest (as is, 
>> *unsafe*) case:
>>
>>   function autoload_all ($class)
>>   {
>>     require_once str_replace("\\", DIRECTORY_SEPARATOR, $class) . ".php";
>>   }
>>
>>   spl_autoload_register("\\autoload_all", true);
>>
>> [Note that the autoloader can be in a namespace itself, which reduces the 
>> risk of namespace collisions for *its* declaration.  That also makes it 
>> easier to autoload only the classes "in the autoloader’s jurisdiction".]
>>
>> IOW, the problems that you are presuming simply *do* *not* *exist*.
> 
> Great explanation, a wonderful reference for anyone needing to
> understand these topics better.
> 

And it solves no problem.  These problems *do exist* in real life.  But
Pointed Head is well known in multiple newsgroups as a know-nothing troll.


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

[toc] | [prev] | [next] | [standalone]

#16992

Jerry Stuckle wrote:

> On 8/28/2016 12:00 AM, Matthew Carter wrote:
>> Thomas 'PointedEars' Lahn <PointedEars@web.de> writes:
>>> IOW, the problems that you are presuming simply *do* *not* *exist*.
>> Great explanation, a wonderful reference for anyone needing to
>> understand these topics better.
> 
> And it solves no problem.

It solves the problem that dependencies have to be resolved manually, which 
was the problem of the OP.

> These problems *do exist* in real life. 

Only to the incompetent.

-- 
PointedEars
Zend Certified PHP Engineer 
<http://www.zend.com/en/yellow-pages/ZEND024953> | Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#16993

On 8/30/2016 5:39 AM, the troll Thomas 'Pointed Head' Lahn wrote:
> Jerry Stuckle wrote:
> 
>> On 8/28/2016 12:00 AM, Matthew Carter wrote:
>>> Thomas 'PointedEars' Lahn <PointedEars@web.de> writes:
>>>> IOW, the problems that you are presuming simply *do* *not* *exist*.
>>> Great explanation, a wonderful reference for anyone needing to
>>> understand these topics better.
>>
>> And it solves no problem.
> 
> It solves the problem that dependencies have to be resolved manually, which 
> was the problem of the OP.
> 
>> These problems *do exist* in real life. 
> 
> Only to the incompetent.
> 

It doesn't solve the problem of multiple classes with the same name.
It's all too easy to load the wrong class.

But someone as incompetent as you are wouldn't know about testing and
migrating versions of code.  You've never had a successful project in
your life.  Just like you've never been able to be a successful ditch
digger because you don't know which end of the shovel to use.

You are just an incompetent troll - well known as one in multiple
newsgroups.

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

[toc] | [prev] | [next] | [standalone]

#16994

Jerry Stuckle wrote:

> On 8/30/2016 5:39 AM, the troll Thomas 'Pointed Head' Lahn wrote:
>> Jerry Stuckle wrote:
>>> On 8/28/2016 12:00 AM, Matthew Carter wrote:
>>>> Thomas 'PointedEars' Lahn <PointedEars@web.de> writes:
>>>>> IOW, the problems that you are presuming simply *do* *not* *exist*.
>>>> Great explanation, a wonderful reference for anyone needing to
>>>> understand these topics better.
>>> And it solves no problem.
>> 
>> It solves the problem that dependencies have to be resolved manually,
>> which was the problem of the OP.
>> 
>>> These problems *do exist* in real life.
>> Only to the incompetent.
> 
> It doesn't solve the problem of multiple classes with the same name.

That was _not_ the problem of the OP.  It was an unfounded assumption by 
“J.O. Aho” who did not read the OP carefully, too.  The OP got

| Fatal error: Class 'Model' not found in /var/www/index.php on line 12

(which arguably should have been posted as plain text instead of a URL of an 
image)

for

  $class = new Model();

So the include must have been wrong.  Had an autoloader been used (or maybe 
it had, but incorrectly; who knows), an include would not have been 
necessary, the file path would have not mattered, the include would not have 
failed, and the class could have been loaded.  *IOW, dependencies would not 
have had to be resolved manually, with the potential of failure.*

> It's all too easy to load the wrong class.

AISB, this is only a problem for the incompetent.

One simply does not have *multiple* classes with the *same* name in the 
*same* namespace loaded in the *same* program/application, because *PHP does 
not allow it* – autoloader or not.  Because of this, one also simply does 
not have *multiple* classes with the *same* name in the *same* directory to 
begin with.  Where multiple versions are available, they are supposed to be 
in different directories or different namespaces, and in different revisions 
of a VCS, to be checked out on an as-needed basis (as Matthew already 
indicated).

Only the *utterly incompetent* would do otherwise.

And if one uses an autoloader for loading classes (which one should), the 
problem disappears in a puff of program logic by choosing the right one, by 
not choosing more than one, or – this is up to the class author; again, a 
matter of competence – to register the autoloader in such a way that there 
is no namespace conflict (as I explained before).

Please stop wasting our precious time by projecting your incompetence.

-- 
PointedEars
Zend Certified PHP Engineer 
<http://www.zend.com/en/yellow-pages/ZEND024953> | Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#16995

On 8/30/2016 8:41 AM, the well-known troll Thomas 'Pointed Head' Lahn wrote:
> Jerry Stuckle wrote:
> 
>> On 8/30/2016 5:39 AM, the troll Thomas 'Pointed Head' Lahn wrote:
>>> Jerry Stuckle wrote:
>>>> On 8/28/2016 12:00 AM, Matthew Carter wrote:
>>>>> Thomas 'PointedEars' Lahn <PointedEars@web.de> writes:
>>>>>> IOW, the problems that you are presuming simply *do* *not* *exist*.
>>>>> Great explanation, a wonderful reference for anyone needing to
>>>>> understand these topics better.
>>>> And it solves no problem.
>>>
>>> It solves the problem that dependencies have to be resolved manually,
>>> which was the problem of the OP.
>>>
>>>> These problems *do exist* in real life.
>>> Only to the incompetent.
>>
>> It doesn't solve the problem of multiple classes with the same name.
> 
> That was _not_ the problem of the OP.  It was an unfounded assumption by 
> “J.O. Aho” who did not read the OP carefully, too.  The OP got
>

No, it is a problem caused by your "solution".  And an even bigger
problem than the ops, because it is not evident.

> | Fatal error: Class 'Model' not found in /var/www/index.php on line 12
> 
> (which arguably should have been posted as plain text instead of a URL of an 
> image)
> 
> for
> 
>   $class = new Model();
> 
> So the include must have been wrong.  Had an autoloader been used (or maybe 
> it had, but incorrectly; who knows), an include would not have been 
> necessary, the file path would have not mattered, the include would not have 
> failed, and the class could have been loaded.  *IOW, dependencies would not 
> have had to be resolved manually, with the potential of failure.*
>

And potentially cause even worse problems.

>> It's all too easy to load the wrong class.
> 
> AISB, this is only a problem for the incompetent.
> 
> One simply does not have *multiple* classes with the *same* name in the 
> *same* namespace loaded in the *same* program/application, because *PHP does 
> not allow it* – autoloader or not.  Because of this, one also simply does 
> not have *multiple* classes with the *same* name in the *same* directory to 
> begin with.  Where multiple versions are available, they are supposed to be 
> in different directories or different namespaces, and in different revisions 
> of a VCS, to be checked out on an as-needed basis (as Matthew already 
> indicated).
> 
> Only the *utterly incompetent* would do otherwise.
>

Well, then I guess there are millions of "incompetent" programmers out
there, according to your definition.  Because programmers all over the
world have multiple versions of software on their systems.

For instance, when you upgrades a CMS to a new version, you don't
migrate dozens of websites on the same server using it all at once.  You
back up one, migrate it and test.  If it works, you make the migrated
version live.  Then repeat the process for other web sites on that server.

And the different versions of the CMS all have the same class names and
the same namespaces.  And they are all live on the system at the same
time.  Keeping them in different directories doesn't work if you're
using an autoloader.  Only one of the versions will load the correct
files; the others will load files belonging to a different version.

Staged upgrades like this are used all over the world.  So I guess all
of those people are "incompetent".  At least according to you they are.
Maybe it's YOU that's incompetent.  No - forget the "maybe".

> And if one uses an autoloader for loading classes (which one should), the 
> problem disappears in a puff of program logic by choosing the right one, by 
> not choosing more than one, or – this is up to the class author; again, a 
> matter of competence – to register the autoloader in such a way that there 
> is no namespace conflict (as I explained before).
> 

And create more, even harder to find problems.

> Please stop wasting our precious time by projecting your incompetence.
> 

Yes, please do.  Your total lack of understanding of how the real world
operates is once again showing.  As is your total incompetence.

But once again, that is well-known my people in multiple newsgroups.  So
that's no surprise.

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

[toc] | [prev] | [next] | [standalone]

#16996

Jerry Stuckle wrote:

> On 8/30/2016 8:41 AM, the well-known troll Thomas 'Pointed Head' Lahn
                            ^^^^^^^^^^^^^^^^        ^^^^^^^^^^^^^^
It takes one to know one.

> wrote:
>> Jerry Stuckle wrote:
>>> On 8/30/2016 5:39 AM, the troll Thomas 'Pointed Head' Lahn wrote:
>>>> Jerry Stuckle wrote:
>>>>> On 8/28/2016 12:00 AM, Matthew Carter wrote:
>>>>>> Thomas 'PointedEars' Lahn <PointedEars@web.de> writes:
>>>>>>> IOW, the problems that you are presuming simply *do* *not* *exist*.
>>>>>> Great explanation, a wonderful reference for anyone needing to
>>>>>> understand these topics better.
>>>>> And it solves no problem.
>>>>
>>>> It solves the problem that dependencies have to be resolved manually,
>>>> which was the problem of the OP.
>>>>
>>>>> These problems *do exist* in real life.
>>>> Only to the incompetent.
>>>
>>> It doesn't solve the problem of multiple classes with the same name.
>> 
>> That was _not_ the problem of the OP.  It was an unfounded assumption by
>> “J.O. Aho” who did not read the OP carefully, too.  The OP got
>
> No, it is a problem caused by your "solution".

Nonsense.

> And an even bigger problem than the ops, because it is not evident.

You have no clue what you are talking about.  Different to the OP, an 
autoloader would use “require_once” *by definition* (I said in my first 
followup that using “require_once” instead of “include” in the original code 
is the first step in analysing the problem; Christoph said “require” 
before).  “require_once” generates a “Fatal error” if inclusion fails.  The 
stack trace produced and a potential custom exception shows the problem and 
where it originated.
 
>> […]  *IOW, [with an autoloader] dependencies would not have had to be
>> resolved manually, with the potential of failure.*
> 
> And potentially cause even worse problems.

In your wet dreams.
 
>>> It's all too easy to load the wrong class.
>> 
>> AISB, this is only a problem for the incompetent.
>> 
>> One simply does not have *multiple* classes with the *same* name in the
>> *same* namespace loaded in the *same* program/application, because *PHP
>> does not allow it* – autoloader or not.  Because of this, one also simply
>> does not have *multiple* classes with the *same* name in the *same*
>> directory to begin with.  Where multiple versions are available, they are
>> supposed to be in different directories or different namespaces, and in
>> different revisions of a VCS, to be checked out on an as-needed basis (as
>> Matthew already indicated).
>> 
>> Only the *utterly incompetent* would do otherwise.
> 
> Well, then I guess there are millions of "incompetent" programmers out
> there, according to your definition. 

There probably are (there are always millions of people incompetent in a 
field against a few competent ones), but not according to the definition 
above.

You simply cannot read carefully.  Because you do not want to.

> Because programmers all over the world have multiple versions of software
> on their systems.

The part that you *still* do seem to get is that there is a difference 
between having several versions, using several versions, and loading several 
versions.  You "overlooked" “different directories”, too.

Enough of your hot air.  Put your money where your big mouth is.  Unless you 
can present an easily reproducible, *real-world* example – and I mean 
*files* of *PHP source code*, at least one program file and two class 
files –, where *properly* using an autoloader in a *proper* setup (as I 
described) would cause *new* problems that would *not* exist without using 
an autoloader (you need to describe those problems in sufficient detail, 
then; no wild assumptions), EOD for me.
 
-- 
PointedEars
Zend Certified PHP Engineer 
<http://www.zend.com/en/yellow-pages/ZEND024953> | Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.php

csiph-web