Is anyone really using the Thread type?
/ Martin Nilsson (DivX Networks)
Previous text:
2004-10-14 13:15: Subject: Re: distinction between modules and classes? (Was: Re: MySQL big_query in 7.7)
Yes, but the really sinister badness becomes apparent later on as more functionality is added. There are two different sets of functions that are placed in classes and modules:
o The functions placed in modules are meaningless to inherit and to include in the type check (hence the need to make them optional). In the discussion about making Sql.Sql a module, such a function is `(). It only exists to be compatible with the Sql.Sql("...") syntax to get a database connection, but you also get a `() in the resulting object which only is confusing and might make errors harder to detect.
o The functions placed in classes are meaningless to call with the module syntax, and if you make a module of a class you get a meaningless object instance. In the Sql.Sql module example, the master will create an object for the module hierarchy, but as opposed to all other Sql.Sql objects, that one doesn't correspond to an actual database connection. It's possible to make calls like Sql.Sql.query which are bogus (but they will probably fail sooner or later when trying to call a function that lacks a definition in Sql.Sql).
An excellent example of how horrible it can get is the Thread module. Someone thought it'd be neat if the type name for thread objects was Thread and not Thread.Thread. Thus there's a shitload of optional functions there, because in reality there are many things that belong in a thread module but not in the thread objects (Mutex, Queue, all_threads, to name a few). Furthermore, if the type name is Thread, it's reasonable to expect that you can inherit it to make your own thread objects with some extra context. That doesn't work, since Thread.pmod overrides create() to avoid a thread being created when the module is compiled.
/ Martin Stjernholm, Roxen IS