Good your already on top of this , thought so but wanted to be sure.
> Ok so what is the story here ,, I think objects , interfaces and modules >> all doing encapsulation is 1 layer too many . >> > > Two, actually. :-) > Even better. > > >> When you have an interface of statics functions ( ie a type class or a >> collection of functions ) , then it begins overlapping the role of modules. >> > > Yes. And I was therefore hopeful that perhaps modules could be replaced by > static interfaces. If that works, then we can eliminate a concept from the > language. If not, then we can't. > > What I forgot is that module names are tied up in the package namespace, > which is a different namespace from the identifier namespace. > Thats just global space for the package . Why does It need to be that way ? > > >> Is it viable reverting modules to namespaces ? Modules are needed with >> type classes but can interfaces with namespaces do that for bitc ? >> > > I don't know why modules are needed for type classes. As to the rest, > that's the question I'm wondering about too: can interfaces replace > modules? > Are they not need to encapsulate / hide data types and especially their creation . In Java / C# interfaces are the contract for modules but its a bit clunky since you need a reference object . So you have to create a object which holds the sub types and methods. So the holder object and interface in combination are a module which is not as efficient . This whole static interface concept makes me go gaga ( I still have to respond to the other emails but i need to make a leap ) . Its a contract to what , ok a contract to functions present in an Assembly ? Across assemblies ( like type classes) ? Or can you use a static class as your holder ( this is not allowed in C# /Java as interface on static is meaningless) which replaces module. Is static class a name for a module ? Ben
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
