IRC Networks
Irc Logs Stats
Start date: 2007-09-27 02:48:27
Last update: 2008-10-24 20:19:38
Channels: 41
Logged Lines: 6230436
Size: 1822.19 MB
Powered by
Channel Info
Network: freenodeChannel: #csharp |
Search in www.irclog.org
Log from #csharp at freenode 2006-06-14
[00:27]<vynvyv>GoatCheez: i'm sure your question can be reduced
[00:28]<gjrvcxnne>bah, i'm just trying to make ppl's heads explore
[00:29]<gjrvcxnne>((D)F).Bob();
[00:29]<vynvyv>GoatCheez: do you post on thedailywtf.com?
[00:29]<gjrvcxnne>uhhh yeah, y
[00:29]<vynvyv>cause i've seen you post
[00:29]<gjrvcxnne>oh, tru tru
[00:29]<gjrvcxnne>Jeff S is a *(&&^tard
[00:29]<gjrvcxnne>he's a mod, but he's so argumentative
[00:30]<vynvyv>i think that's pretty weird that the method that gets called depends on how you cast the object
[00:30]<vynvyv>i just discovered the site, i don't know who he is
[00:30]<vynvyv>Arild: that only happens if the class implements the same method from 2 different interfaces right?
[00:30]<vynvyv>otherwise, casting has no affect?
[00:30]<azyfm>yeah
[00:30]<vynvyv>ok that's good to know
[00:30]<gjrvcxnne>yeah
[00:31]<gjrvcxnne>lol
[00:31]<y-gz>http://pastebin.ca/index.php
[00:31]<y-gz>ops
[00:31]<y-gz>http://pastebin.ca/65257
[00:31]<y-gz>Here... a real life situation
[00:31]<y-gz>:)
[00:31]<y-gz>with interfaces
[00:31]<y-gz>:)
[00:31]<vynvyv>uh ok
[00:31]<gjrvcxnne>roflmao
[00:38]<cfudsd>i implemented designerhost a few years ago, making a runtime forms designer, where the user could edit and rearrange a form at runtime
[00:38]<cfudsd>it was tedious
[00:38]<cfudsd>thats all i remember
[00:40]<vynvyv>there's nothing wrong with interface inheritance imo
[00:41]<vynvyv>a common thing is to have IXGet, IXSet
[00:41]<vynvyv>and an interface that extends both
[00:41]<vynvyv>the factory method initalizes the interface that extends both but only returns the IXGet
[00:41]<vynvyv>that way, the object becomes immutable
[00:41]<vynvyv>except in the factory method
[00:42]<vufvuzn>(not immutable - unmodifiable by some users)
[00:42]<fz1dbz>hey
[00:42]<vynvyv>it's immutable past a certain point
[00:42]<fz1dbz>how do we get the datetime string thats (default)
[00:42]<fz1dbz>from the computer running the program?
[00:42]<vynvyv>if you want to be that strict, the only things that are immutable are constants right?
[00:42]<cfudsd>thedailywtf, thats so funny
[00:42]<fz1dbz>?
[00:43]<cfudsd>that site that somebody linked, its a crack up
[00:43]<y-gz>I think in the case of
[00:43]<vynvyv>vulture: i also think it depends on your perspective. the IXGet is immutable I think
[00:43]<y-gz>http://pastebin.ca/65257
[00:43]<vufvuzn>tieTYT: well not quite - a 'constant' is usually constant at compile-time. An immutable object could be created at runtime.
[00:43]<y-gz>one is forced to implement IServiceContainer, IServiceProvider explicitly ?
[00:43]<y-gz>dunno
[00:43]<vynvyv>vulture: ok, well when people say immutable objects, i don't think they normally referring to constant/readonly
[00:44]<gjrvcxnne>vulter: not always so, rememeber: it depends on what your definition of "is" is
[00:44]<vufvuzn>tieTYT: if the result of retrieving values from an IXGet can change over time (even if you can't be the source of such changes) I wouldn't call it immutable
[00:45]<vynvyv>vulture: well what if the method that returns IXGet takes a parameter and that defines what's in the IXGet
[00:45]<vynvyv>can it still be immutable?
[00:45]<vufvuzn>tieTYT: creation isn't the issue - you can create something and thereafter it may never change - that's immutable.
[00:45]<vufvuzn>but just because _you_ can't change it, but someone else can, that's not immutable, it's just that you can't modify it
[00:46]<vynvyv>vulture: i think that was the example i first presented
[00:46]<vufvuzn>immutable would be that which doesn't change - maybe you can only look but can't touch - you can still _see_ it changing
[00:46]<vynvyv>oh i see what you're saying
[00:46]<vynvyv>the factory method is modifying it after creation
[00:46]<cfudsd>nothing is immutable in sofware then, other than ROM
[00:47]<vynvyv>vulture: so if an immutable object has a calendar
[00:47]<vynvyv>and you say, getTime() over and over again
[00:47]<vufvuzn>klumsy: yes, there are ways of going around immutable/unmodifiable interfaces to members, but I'm not talking about using a chainsaw
[00:47]<vynvyv>it will always return a different value
[00:47]<vynvyv>iyo, that's immutable?
[00:47]<cfudsd>vulture :)
[00:48]<vufvuzn>tieTYT: then the issue becomes a matter of what constitues the "object" - is the time member part of the calendar, or just referenced by the calendar (it's a design/philosophical question now)
[00:49]<vufvuzn>the strictest definition would be only the actual values in the object (so the references (not the things they reference) and value types) - but then a string object could be immutable if it didn't change wihch char[] it refered to, even if the chars in the currently referenced array were to change value
[00:50]<vufvuzn>that's hardly the appropriate definition. So what constitutes the object's state doesn't follow a simple concrete rule
[00:50]<vynvyv>anyway i only care about the benefits you get from using immutable objects
[00:51]<vynvyv>so all that matters to me is, if the factory method returns an unmodifiable object, am i getting all the benefits?
[00:51]<vufvuzn>what benefits are you hoping to get?
[00:51]<vynvyv>simplier to test
[00:52]<vufvuzn>how is it simpler to test?
[00:52]<vynvyv>also, you can return the same reference over and over again
[00:52]<vynvyv>because the object will not change over time
[00:52]<vynvyv>and it will have no state
[00:52]<vynvyv>you can call any method in any order once you get it
[00:52]<vufvuzn>but you said that there is an IXSet interface that is implemented
[00:52]<vynvyv>yes but you don't get that
[00:52]<vufvuzn>so why odes it exist?
[00:52]<vynvyv>you get IXGet
[00:53]<vynvyv>so that the factory method can use it to initialize the object
[00:54]<vufvuzn>if the thing is truely immutable it should be a concrete type that cannot be derived from. If it's only unmodifiable via one interface then I'd still want to be testing the interaction of state changes.
[00:54]<vufvuzn>(concrete type that cannot be derived from _and has no modifying operations_ of course)
[00:55]<vynvyv>hrm
[00:55]<vufvuzn>If you insist that no one can see this private modification interface (by making that interface and the implementing class private to the factory, for example - or just by big flashing signs & a hope that people follow your instructions) then you could test it as a true immutable
[00:55]<vynvyv>vulture: i generally do the former
[00:56]<vufvuzn>private to the factory? good-o. It's not 100% perfect, but it at least restricts the places you could break immutability to a finite area (the factory).
[00:56]<vufvuzn>just as trying to make a concrete immutable class restricts the places you can mess-up to a finite area.. so the difference isn't great
[00:58]<vynvyv>this is what i do, if you could tell me what you think about it
[00:58]<vynvyv>forget what we've said already
[00:58]<vynvyv>i usually have one interface that only has getters
[00:59]<vynvyv>i make one (or more) classes implement it that contain setters also. These classes are package private (sorry, java term. means you can't use them outside the namespace i guess)
[00:59]<vynvyv>the concrete classes have no constructors, only a factory method to get an instance of itself
[00:59]<vufvuzn>I'm aware of the term (but wonder why you are asking Java questions in C#)
[00:59]<vynvyv>this is language independent, i just did it in java
[00:59]<vufvuzn>no non-private ctors I assume you mean







