Re: What’s the best way to check if a feature/class has been loaded?

Your emails mix classes, constants, and paths.

If paths is what you want to check then we need to leave classes and constan=
ts completely out of the thread. Do you agree with that?

Do you also agree in that checking if a path belongs to $" tells you nothing=
 about the constant it defines, if any?

Sent from my iPhone

On 22/03/2012, at 8:03, Nikolai Weibull <[e-mail]> wrote:

> On Thu, Mar 22, 2012 at 06:56, Xavier Noria <[e-mail]> wrote:
>> On Thu, Mar 22, 2012 at 6:15 AM, Nikolai Weibull <[e-mail]> wrote:
>=20
>>>  I see that you completely cut out the part about const_defined? not
>>> calling const_missing, which is a rather big part of the problem with
>>> using const_defined? in the first place.
>=20
>> We are supposedly emulating defined? somehow but for constant paths and
>> without going up the ancestor chain in each step doesn't it? defined? doe=
s
>> not call const_missing.
>=20
> True, I was seeing the wrong test output for that one.
>=20
>>> An alternative is to check $LOADED_FEATURES.  This isn=E2=80=99t
>>> straightforward either, as it doesn=E2=80=99t contain the exact argument=
 given
>>> to require.  There are internal functions like rb_provided that could
>>> have been exposed to make it easy to check if a feature had been
>>> loaded/is available.
>=20
>> File names and class objects, and module objects, and constants... you
>> cannot derive one from the other. They are decoupled in Ruby except for t=
he
>> fact that the class/module keywords assign, and that if you assign an
>> anonymus class/module to a constant, then its name is set after the
>> constant.
>>=20
>> But in Ruby file foo.rb can define the constant Bar, which may hold a mod=
ule
>> whose name is "Wadus". They are quite orthogonal features.
>=20
> Yes, I realize that, but let=E2=80=99s forget the constant bit (as I tried=
 to
> do in the part that you cut out from the rest of this discussion on
> $LOADED_FEATURES, require, and provided?) and focus on the original
> problem of determining if a feature is available or not.  In my first
> e-mail I explained that I=E2=80=99d been using defined? to perform such te=
sts,
> but that it doesn=E2=80=99t work as intended.  I proposed an alternative t=
o
> defined? that tried to walk a constant path without ever returning to
> the top level, but I wasn=E2=80=99t happy with the solution and, as we=E2=80=
=99ve
> seen, there are semantic issues with such a solution (should
> const_missing be called or not?).  I was, however, originally looking
> for a better alternative to the constant lookup altogether.  That=E2=80=99=
s
> why I mentioned =E2=80=9Cfeature=E2=80=9D in my first e-mail.
>=20
> As I said, Ruby uses the (expanded) path of the argument to require as
> the =E2=80=9Cfeature=E2=80=9D.  If Ruby provided a convenient way to check=
 if a path
> was in $LOADED_FEATURES that=E2=80=99d solve my use case.  This can of cou=
rse
> be emulated, and I=E2=80=99m surely making too big a deal about this, but I=
=E2=80=99d
> rather have Kernel.provided? that wraps the extant rb_provided than
> having to define
>=20
> def provided?(path)
>  $LOADED_FEATURES.any?{ |e| e.end_with? path + File.extname(e) }
> end
>=20
> for each project that needs this functionality.  Finally, such a
> definition can never truly emulate rb_provided (or what the return
> value would be from require), as Ruby doesn=E2=80=99t expose the =E2=80=9C=
loading=E2=80=9D
> table.  (This solution won=E2=80=99t take autoloads into account either, i=
f
> one wants that to be done, but they=E2=80=99re going away in 3.0, so let=E2=
=80=99s
> ignore them ;-)
>=20