Type.type.php File Reference
Go to the source code of this file.
Detailed Description
- Developer log entry:
- Necdet Can Atesman (2009-01-27): Versioning DataObjects actually does not make any sense, since a minor version change would imply that a member has been added, while a major version change would indicate that the objects are completely incompatible. ICE has a nice feature called factes, which solves versioning quite well. To put their idea short: every object exports multiple interfaces which allow different peers to access the object in various ways. But since we're not handling any remote objects, we could regard each member as a facet. This consideration leads us to the idea that members are compared by the equality of their name/type combination. This would allow us to arbitrarily change our local definition of the type. As long as the remote peer has the same members as we do, both versions are compatible. To allow even more compatibility, we could allow marking certain members as optional. This would come in handy with function objects, too.
- Developer log entry:
- Joyce Visne (2009-01-23): There is no difference between double and float results (in php they are the same)
- Developer log entry:
- Necdet Can Atesman (2009-02-10): Current issues:
- What do we do with Type windows?
- Do we keep the name?
- TypeWindows have TypeWindows as members/parents, so they're kept in parallel to the actual types. Is there a nicer way to implement this?
- How do we handle service types?
- Does a service type really need its own class? Wouldn't it be enough to generate additional information out of the already-processed documentation?
- How do we handle array types? Anything here applies to map types as well.
- Do we really need the abstract type 'array'?
- Do we really need some abstract form of inheritance here?
- isArray() should be refactored, using strings is pointless here.
- How do we proceed with shared objects?
- Are they accessed as usual? Do they have any implicit limitations?
- Developer log entry:
- Necdet Can Atesman (2009-02-12): Let's go through those questions above one by one:
- TypeWindow: A TypeWindow is actually the same as a type. The only real difference is that TypeWindows are declared using other Types, as opposed to the generation out of source code. Furthermore, they don't have a class name to be used to create an instance, since they use the predefined classes. The question comes down to "Are TypeWindows visible outside their package?". This question is discussed along Shared objects, below.- Services: Services should actually be regarded as standard types with additional data attached to them. Furthermore they must provide a method to retreive the result for the actual computation (an abstract function getResult() or something similar). The additional data that is required by more static languages is confined to the exception types that could be thrown and the type of the return value. The latter can be solved by requiring a member called "result" and demanding a documentation - including its type - for it. The exceptions thrown could as well be stored in the documentation of the class, or in the documentation of the very same result member.
- Arrays/Maps: These types should have their own classes, since they provide more information than the other types. This idea actually lead me to the solution that there are multiple types that can be distinguished:
- BuiltinType (int, real, string, ...)
- UserType
- Shared objects: The questions aboved arised from the confusion regarding TypeWindows: The actual question should have been, whether TypeWindows should ever leave the network package. The following implementation could be possible:
- interface IType
- class LocalType implements IType
- class RemoteType implements IType
- class SharedType implements IType
SharedType would be our TypeWindow in the above example. A simpler solution would be to ban TypeWindows to the network package and live outside of that with Type only. This looks like the more durable solution, since the networking layer should be absolutely transparent to the programmer which could mean that the peer providing the service could be a different one than the one used during the first call, which would again result in a new TypeWindow. The Type hierarchy outlined above is not too bad either, but the resulting classes should not be used outside of their target packages.
Update: After finishing the analysis about Arrays and Maps above, I noticed that the only type that can be received by other peers are UserTypes. So this is the only class that we need subtypes for.
- Developer log entry:
- Necdet Can Atesman (2009-02-16): Thoughts on caching: If caching is intended to dump the variable $_cache into a file and possibly restore it through a call to unserialize(), it is not possible to cache individual modules. It's an all-or-nothing approach, since PHP can't store references to unserialized values. This means that if one tries to store the type User, which is has the DataObject as its parent, both type objects would be serialized - User and DataObject. If both types are from different packages, this would mean, there would be two type objects describing the DataObject class.
Another approach would be to replace links to types of other modules with their string representations. This would render the whole initialization extremely complicated, though. So we'll stick to this very conservative caching method.
- Developer log entry:
- Necdet Can Atesman (2009-02-16): Regarding speed: A brief profiling of the code revealed that the bottleneck of the initialization is the automatic scanning of the source folders. Another caching mechanism is introduced that will write the list of source files into an include file and include that one instead of scanning the whole directory each time.
- Developer log entry:
- Necdet Can Atesman (2009-06-03): Annotating basic types with options gives great control on the user types. The name of a user can be restricted to a certain length, within PHP itself. The number of entries in an array can be defined, allowing one to guarantee that an array will never have more than x entries. This features makes some of the types obsolete, actually. There is no need for a short type, since it is merely a signed integer with a given range. These types of optimizations are not needed anymore nowadays (especially not if one is working in PHP). The other unnecessary value is one of the floating-point types (float/double). Having one floating-point value (called real, for example) should be perfectly enough. The last numeric type - byte - could be needed for convenience, though, so it will stay a discrete type in the framework.
Type declarations could have some of these attributes attached, like the available range for example - merely for convenience, since we cannot express everything in a single type description. One example could be array<int(0,10)>(1,4): An array containing 1-4 integers, each of which being between 0 and 10. But adding the assertion that the integers should all be odd, between (0 and 3) or (10 and 13) and should be divisible by 7 doesn't need to be expressed that way :)
- Developer log entry:
- Necdet Can Atesman (2009-07-15): Removed the charset option today. Comparing using different character sets in mysql does not make use of any indexes and it is not necessary outside the database.
- Developer log entry:
- Necdet Can Atesman (2009-08-20): Reading through the devlogs today I had an idea about the type cache: Currently, the type cache stores all references of all types, thus all types, including the singleton instances of the builtin types. The momentary workaround involves returning all singletons as reference and replacing the value with the unserialized one.
Another approach might be to replace these references with strings before serializing the types. This would make it more robust, but could as well lead to some performance loss, since we would need to iterate over all user types and replace their member types with objects when unserializing (and that part should actually be as fast as possible).
Definition in file Type.type.php.
