On Mon, Sep 2, 2013 at 7:51 AM, Bennie Kloosteman <[email protected]>wrote:
> Note the performance cost in C# strings str.SubString ( Indexof( > lookupString) , length) requires creating a new string each time. We > disussed a mutable ptr / length slice lookup previously ( even using a 64 > bit pointer with the length in the high bits) which would be nice but it > wont work with C# string as the array is private. > >From my perspective, the problem is not the array being private, but string methods being non-virtual. If everything is virtual/interface-based, then you can make your own string-slice implementation which looks just like a normal string. With the caveat that this puts more pressure on the JIT/inliner/polymorphic-inliner. This is the source of a previous comment of mine that I'd like to forbid implementation-names from appearing as type-parameters, only allowing interface names -- or alternatively, allowing you to "implement" a type without inheriting it's interface (like Sather, or Google-Go). IMO, static languages allowing type-paramaters to name concrete class-type-implementations is one of the legitimate reasons the dynamic-typing camp still gets to laugh and point fingers at us static-typers, as it causes too much type inflexibility in code. For example, in JVM every method *is* virtual, but you still can't make a string-compatible string-slice, because string is final, so you can't make a new implementation of it which you can pass to existing string-paramater types. In all dynamic dispatch systems (Smaltalk, SELF, Python, Ruby, Objective-C, etc, etc), you can just implement your own string-slice which has the same method-protocols as a string, and hand it to any string paramater without trouble.
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
