Reputation
3,759
Top tag
Next privilege 5,000 Rep.
Approve tag wiki edits
Badges
6 14
Newest
 Yearling
Impact
~270k people reached

  • 0 posts edited
  • 0 helpful flags
  • 167 votes cast
1d
comment Is it bad or good to wrap mutable objects in immutable containers?
An immutable container of mutable objects is immutable if no chain of events would cause a reference to those mutable objects to be exposed to code that would mutate them. If the code which creates the container has never exposed the mutable object to anything that might mutate it, and it knows that the container doesn't do so either, then the code which creates the container can know that it is immutable. The difficulty is that recipients of the container can't know what degree of care its creator took in guarding its contents, unless the container itself creates those contents.
1d
comment Is it good practice to catch a checked exception and throw a RuntimeException?
It might be good to mention that this sort of issue can really wreak havoc in cases where a method runs a function which is supplied by its caller. The author of the method receiving the function will in many cases have no reason to know nor care what the caller is expecting it to do, nor what exceptions the caller might be expecting. If the code receiving the method isn't expecting it to throw a checked exception, the method being supplied may have to wrap any checked exceptions it would throw in unchecked exceptions that its supplier could then catch.
1d
comment Why is object-level privacy difficult to use as a paradigm, and why is it desirable?
...any particular implementation needing to trust any other, provided that all implementations "trusted" an ArraySource<T> class. The list to be read would construct an ArraySource<T> which would receive (but never expose) its array internals; the destination would pass its backing store to that ArraySource<T> which would then perform a suitable bulk-copy operation (or sequence thereof). The ArraySource would need access to both IList<T>s' arrays, but neither IList<T> would ever be exposed to the other one's array.
1d
comment Why is object-level privacy difficult to use as a paradigm, and why is it desirable?
@BillyONeal: Consider a type like List<T>, which has a private backing store of type T[]. If it's necessary to copy a range of items from one List<T> to another, the ability of one to access the T[] of the other allows such copies to be efficient, but does nothing to improve the efficiency of copying items from any other kind of IList<T> to a List<T> or vice versa. I would suggest that a better designed class could allow for efficient copying between any two implementations of IList<T> which store groups of consecutive data items consecutively in backing arrays, without...
1d
comment Why is object-level privacy difficult to use as a paradigm, and why is it desirable?
...to have a class be substitutable for multiple other classes rather than actually inherit members from all of them, this approach would make it possible to have objects that behaved as though they inherited from multiple classes without requiring that they actually do so (a typical pattern would be for an object to inherit from one primary parent class, own a reference to an instance of each other supplemental parent class, and provide implementations of those latter classes' public members which chained to corresponding members of the owned instances.
1d
comment Why is object-level privacy difficult to use as a paradigm, and why is it desirable?
@BillyONeal: If a language does not allow methods of a class Foo receiving a parameter of type Foo to use the private members of the object identified thereby, then the language can allow classes to be derived from Foo in two ways: (1) The derived class inherits all members of the base type; (2) The derived object does not inherit any members of the base type, and must implement all public members itself, but instances could then be passed to code expecting the base type. Since inheriting members from multiple base classes is problematic, and since it's generally more important...
2d
answered Why would I care about the asymptotic growth of the lower bound of the worst case time/space?
2d
comment When speaking, how can I say that the time complexity order of an algorithm is O(N log N)?
@Kevin: Logarithmic is four syllables, but "log-enn" is only two. Likewise, O(N^2) is "enn-squared", not "quadratic". I suppose "cubic" has fewer phonemes than "enn-cubed", but I think the latter term would still be more common.
Jul
26
comment Why is object-level privacy difficult to use as a paradigm, and why is it desirable?
...the data source could have the data split into multiple backing sections without exposing that fact (or the arrays themselves), and the destination could know that the helper class would never expose the array to the data source, but the helper class would still be able to use bulk-copy operations to move data in cases where the data source could accommodate that.
Jul
26
comment Why is object-level privacy difficult to use as a paradigm, and why is it desirable?
@Deduplicator: You're right; I oversimplified. Doing things properly requires a "trustworthy" class which is instantiated with data from one class object and can do specific actions in relation to another; in systems that support value types, such a thing can be pretty efficient and versatile. For example, if .NET included a suitably designed helper class for the purpose and had IReadableList<T> or a variant thereof support it, it would be possible for any implementation of that type to allow its contents to be quickly copied into an array in such a fashion that...
Jul
25
answered Why is object-level privacy difficult to use as a paradigm, and why is it desirable?
Jul
25
comment Why is object-level privacy difficult to use as a paradigm, and why is it desirable?
Even with object-level privacy, one could implement equal by having a method usesWriter(ostream *writer) and then equal(i_write_things const &other) { return other.usesWriter(this->writer);}.
Jul
25
comment Why don't languages include implication as a logical operator?
I remember IMP from DEC BASIC. I don't remember EQV. The operator I've often wished for would be "and not", which would promote the right-hand operator before negating it. Thus, 0xABCD12345678ul ~& 0x00200000u would yield 0xABCD12145678ul rather than 0x12145678ul.
Jul
23
comment Should I initialize C structs via parameter, or by return value?
@Yakk: Having directives, for example, which would tell a compiler "The following variables may safely be kept in registers during the following stretch of code" as well as a means of block-copying a type other than unsigned char would allow optimizations for which the Strict Aliasing Rule would be insufficient, while simultaneously making programmer expectations clearer.
Jul
23
comment Should I initialize C structs via parameter, or by return value?
@Yakk: Historically, C was invented to serve as a form of high-level assembly language for systems programming. In the years since, its identity has become increasingly murky. Some people want it be an optimized application language, but since no better form of high-level assembly language has emerged, C is still needed to serve that latter role. I see nothing wrong with the idea that a well-written program code should behave at least decently even when compiled with minimal optimizations, though to make that really work would require that C add some things that it has long lacked.
Jul
21
comment Is guaranteeing immutability a justification for exposing a field instead of a property?
A constructor can pass a readonly field as an out or ref parameter to other methods, which will then be free to modify it as they see fit.
Jul
21
comment Do not declare interfaces for immutable objects
@MatthewWatson: Interfaces are often given the "wrong" name [e.g. Microsoft's ReadOnlyCollection<T> should be a ReadableCollection<T>, since it is implemented by types which write to it directly], but if interfaces are given the proper names and clear contracts there's nothing wrong with having interfaces for immutable objects.
Jul
21
comment Do not declare interfaces for immutable objects
@MatthewWatson: There are several kinds of interfaces which have getters but not setters: "readable", "read-only", and "immutable". A readable interface says nothing about whether an implementation might expose setters via some other interface. A read-only interface promises that its implementation will be a read-only view of some object and may be shared with arbitrary outside code that is allowed to have a read-only view but would not be allowed to write the underlying object. An immutable interface promises a view of an object which will never change.
Jul
21
comment Do not declare interfaces for immutable objects
@vaughandroid: If the implementation contract for an interface specifies that all legitimate implementations must be immutable, that will guarantee that all legitimate implementations will be immutable. It will not prevent anyone from writing illegitimate implementations, but it isn't possible for any kind of non-trivial interface to guard against that.
Jul
21
comment Should I initialize C structs via parameter, or by return value?
@cmaster: On platforms which return structures by passing a pointer to temporary storage, C compilers do not provide called functions with any way of accessing the address of that storage. In C++, it's possible to get the address of a variable passed by reference, but unless the caller guarantees the lifetime of the item passed (in which case it usually would have passed a pointer) Undefined Behavior will likely result.