On 2 March 2018 01:38:37 GMT+00:00, "Pedro Magalhães" wrote:
>On Thu, Mar 1, 2018 at 11:04 PM, Rowan Collins
>
>wrote:
>>
>> What *can* break an interface's contract is changing the *visibility*
>of
>> the pasted method using "as protected" or "as private". This would
>need to
>> be captured someh
On Thu, Mar 1, 2018 at 11:04 PM, Rowan Collins
wrote:
>
> What *can* break an interface's contract is changing the *visibility* of
> the pasted method using "as protected" or "as private". This would need to
> be captured somehow while composing the class, probably producing a
> compile-time error
Hi all,
On 01/03/2018 00:34, Marco Pivetta wrote:
- trait defined API can be imported with changed/aliased names, breaking
therefore the contact defined in the interface
This isn't actually true, because trait method aliases create an *extra*
copy of the pasted method, rather than actually
> don't use traits
Yes, in general, yes.
Composition is great, and I use it most of the time.
I still do have some cases where I think that base classes (with
private properties) are justified, and then some cases where either
traits or multiple inheritance would be justified.
We could agree to se
This cannot work for a number of reasons:
- a trait is not a type, and does not practically exist at runtime
- trait defined API can be imported with changed/aliased names, breaking
therefore the contact defined in the interface
- due to the previous point, inheriting a type from a trait become
Why traits doesn't supports interfaces (via implements) like classes does?
It could be useful when trait implements part of abstract functions from
interface, then the class that uses this traits should implements the
another part.
It could turn it possible (pseudo-code):
interface VisibilityCon
