C#

FirstPrevNext

Abstract, Interface, and Attribute TuringTest17-Jan-04 20:40 TuringTest1 7-Jan-04 20:40  what are the design tradeoffs between different constructs to collect objects based on some common functionality? Suppose i want to rely on objects being able to "display" themselves. What's the difference between using Abstract Base, Interface, or Attribute? Since c# doesnt allow multiple inheritance i'd guess Abstract base should be reserved for "core" properties of the object, and i guess Interfaces are there exactly so my displayThyself methods can be expressed. What about [Serializable], that has properties similar to an interface except for specifying a constructor as one of the mandatory methods. Is there a discussion of what construct to use when and why? Thanks in advance! ________________________________________ Gosh, it would be awful pleas'n, to reason out the reason, for things I can't explain. Then perhaps I'd deserve ya, and be even worthy of ya.. if I only had a brain! Re: Abstract, Interface, and Attribute Mazdak7-Jan-04 20:56 Mazdak 7-Jan-04 20:56  TuringTest1 wrote: i'd guess Abstract base should be reserved for "core" properties of the object Yes. TuringTest1 wrote: i guess Interfaces are there exactly so my displayThyself methods can be expressed. Well,you mention that multiple inheritance is not allowed in C#,with Interfaces you can have multiple inheritane,you inherit a class from another class AND how many interface you want. Serializable word express itself.It means you can seriallize this class. MSDN exapain these things very good,you can start from it. Mazy No sig. available now. Re: Abstract, Interface, and Attribute TuringTest17-Jan-04 21:32 TuringTest1 7-Jan-04 21:32  Mazdak wrote: Serializable word express itself.It means you can seriallize this class. MSDN exapain these things very good,you can start from it. yes, [Serializable] is implemented as an attribute, but it really looks like an Interface, doesn't it? except that for technical reasons (one of the 2 interface "methods" is a constructor) it can't be an interface. Or something like that. What are the similarities and differences between something implemented as an Interface and something like [Serializable] which is implemented via attributes? ________________________________________ Gosh, it would be awful pleas'n, to reason out the reason, for things I can't explain. Then perhaps I'd deserve ya, and be even worthy of ya.. if I only had a brain! Re: Abstract, Interface, and Attribute Heath Stewart8-Jan-04 5:32 Heath Stewart 8-Jan-04 5:32  Actually, if you attribute your class with the SerializableAttribute, the default serialization will serialize public and private fields of your class. There is an interface, ISerializable, that allows you to control the serialization so that you, the developer, controls what gets serialized and what doesn't. This does go along - like the original poster mentioned - with a constructor that has the signature (SerializationInfo, StreamingContext). This constructor can have any access modifier, but are common protected so that subclasses can pass serialization info to its base class. There are also other serialization interfaces that can be useful, such as the IDeserializationCallback that allows you to perform any layout or hook-ups after serialization is complete, and the ISerializationSurrogate that - with an IFormatter implementation allows you to serialize Types that are themselves serializable. You can also use a SerializationBinder with the formatter to serialize from one Type to another, using SerializationBinder.BindToType. This seems especially handy when you have to upgrade a serialized file with older versions of Types.   -----BEGIN GEEK CODE BLOCK----- Version: 3.21 GCS/G/MU d- s: a- C++++ UL@ P++(+++) L+(--) E--- W+++ N++ o+ K? w++++ O- M(+) V? PS-- PE Y++ PGP++ t++@ 5 X+++ R+@ tv+ b(-)>b++ DI++++ D+ G e++>+++ h---* r+++ y+++ -----END GEEK CODE BLOCK----- Re: Abstract, Interface, and Attribute TuringTest18-Jan-04 5:51 TuringTest1 8-Jan-04 5:51  So marking class Foo with [Serializable] magically adds expands Foo by implemnting the 2 ISerializable methods ending up with Foo : ISerializable? ________________________________________ Gosh, it would be awful pleas'n, to reason out the reason, for things I can't explain. Then perhaps I'd deserve ya, and be even worthy of ya.. if I only had a brain! Re: Abstract, Interface, and Attribute Heath Stewart8-Jan-04 5:53 Heath Stewart 8-Jan-04 5:53  No, you still have to implement ISerializable if you wish. Just attributing the class as I mentioned before with SerializableAttribute serializes all private and public fields. Implementing ISerializable is required if you want to control what gets serialized. See the ISerializable documentation for both more detail and an example.   -----BEGIN GEEK CODE BLOCK----- Version: 3.21 GCS/G/MU d- s: a- C++++ UL@ P++(+++) L+(--) E--- W+++ N++ o+ K? w++++ O- M(+) V? PS-- PE Y++ PGP++ t++@ 5 X+++ R+@ tv+ b(-)>b++ DI++++ D+ G e++>+++ h---* r+++ y+++ -----END GEEK CODE BLOCK----- Re: Abstract, Interface, and Attribute TuringTest18-Jan-04 6:01 TuringTest1 8-Jan-04 6:01  Heath Stewart wrote: Actually, if you attribute your class with the SerializableAttribute, the default serialization will serialize public and private fields of your class. how does this happen? doesnt it require "somebody" to implement a default ISerializable for the class? or is it just done at runtime via reflection? [[need more smiley flavors for "huh??"!!!) ________________________________________ Gosh, it would be awful pleas'n, to reason out the reason, for things I can't explain. Then perhaps I'd deserve ya, and be even worthy of ya.. if I only had a brain! Re: Abstract, Interface, and Attribute Heath Stewart8-Jan-04 6:12 Heath Stewart 8-Jan-04 6:12  If you'll read the documentation for SerializableAttribute, you'll see that the serialization infrastructure serializes private and public fields by default if a class is attributed (the class itself - inheriting the attribute doesn't make a derivative class serializable). This is done via reflection, yes. Note that your class must be attributed with the SerializableAttribute even if it implements ISerializable to be serializable. Implementing the interface just gives you explicit control over serialization of your Type.   -----BEGIN GEEK CODE BLOCK----- Version: 3.21 GCS/G/MU d- s: a- C++++ UL@ P++(+++) L+(--) E--- W+++ N++ o+ K? w++++ O- M(+) V? PS-- PE Y++ PGP++ t++@ 5 X+++ R+@ tv+ b(-)>b++ DI++++ D+ G e++>+++ h---* r+++ y+++ -----END GEEK CODE BLOCK----- Re: Abstract, Interface, and Attribute TuringTest18-Jan-04 6:39 TuringTest1 8-Jan-04 6:39  ok, i guess i see how this is done-- pls correct me if i'm wrong: on invoking Formatter.Serialize, Formatter uses reflection to check whether ISerializable is implemented in the class of the object. if so it calls the interface. If not it uses reflection to serialize all the fields, checking for the NonSerialized as it goes. is that what happens? and if this is, how is that done efficiently enough to not take forever to serialize each two-bit-- i mean two-byte-- object in the graph? does BinaryFormatter perform some sort of run time analysis or "compilation" like regex? ________________________________________ Gosh, it would be awful pleas'n, to reason out the reason, for things I can't explain. Then perhaps I'd deserve ya, and be even worthy of ya.. if I only had a brain! Re: Abstract, Interface, and Attribute Heath Stewart8-Jan-04 7:13 Heath Stewart 8-Jan-04 7:13  You should read Serializing Objects[^] in the .NET Framework. I think it'll help understand many of these concepts. As far as performance, it is true that reflecting all those fields and Types takes a while but it is necessary when crossing contexts (via Remoting) or serialing to streams for any other means. The process of serialization is actually pretty complex. If you're interested in the details, you should use ildasm.exe (if you know IL) or a good decompiler like .NET Reflector[^] to see how much of that is done. Our application I designed uses A LOT of Remoting in the Internet-deployed edition and it functions pretty fast - not much slower than the LAN version (and most people don't even notice). As far as I can tell, nothing is cached from serialization to serialization either because everything changes from call to call.   -----BEGIN GEEK CODE BLOCK----- Version: 3.21 GCS/G/MU d- s: a- C++++ UL@ P++(+++) L+(--) E--- W+++ N++ o+ K? w++++ O- M(+) V? PS-- PE Y++ PGP++ t++@ 5 X+++ R+@ tv+ b(-)>b++ DI++++ D+ G e++>+++ h---* r+++ y+++ -----END GEEK CODE BLOCK----- Re: Abstract, Interface, and Attribute TuringTest18-Jan-04 7:50 TuringTest1 8-Jan-04 7:50  thanks, yes i also use BinaryFormatter on pretty big objects and it seems remarkably efficient. Thanks for the suggestion on Reflector (do i also need to learn il?). Thanks for the insights and the Reflector fishing rod!! ________________________________________ Gosh, it would be awful pleas'n, to reason out the reason, for things I can't explain. Then perhaps I'd deserve ya, and be even worthy of ya.. if I only had a brain! Re: Abstract, Interface, and Attribute Heath Stewart8-Jan-04 7:52 Heath Stewart 8-Jan-04 7:52  Why not learn IL? You can never know too much. Besides, decompilers don't always do such a great job so you'll have to look at IL at some point to see what's really going on. At least knowing what the instructions do is important, which is also documented in the .NET Framework SDK.   -----BEGIN GEEK CODE BLOCK----- Version: 3.21 GCS/G/MU d- s: a- C++++ UL@ P++(+++) L+(--) E--- W+++ N++ o+ K? w++++ O- M(+) V? PS-- PE Y++ PGP++ t++@ 5 X+++ R+@ tv+ b(-)>b++ DI++++ D+ G e++>+++ h---* r+++ y+++ -----END GEEK CODE BLOCK----- Re: Abstract, Interface, and Attribute TuringTest18-Jan-04 11:39 TuringTest1 8-Jan-04 11:39  yikes! i guess you're right, that probably is the key to a lot of things i wish i knew how they were implemented, but i must admit it sounds fairly daunting!! also brings up a dumb question, is it obvious that the inner loop of the serialization (in BinaryFormatter?) would likely be written in IL not native x86? Thx! ________________________________________ Gosh, it would be awful pleas'n, to reason out the reason, for things I can't explain. Then perhaps I'd deserve ya, and be even worthy of ya.. if I only had a brain! Re: Abstract, Interface, and Attribute Heath Stewart8-Jan-04 12:11 Heath Stewart 8-Jan-04 12:11  All compilers targeting the CLR using pure managed code produce Intermediate Language, or IL. So yes, it is IL. In fact, the Managed C++ compiler is the only compiler publicly available from Microsoft that can produce native code in an assembly (known as mixed mode). But using an loop for serialization would be a poor idea. Recursion is most likely at work since for every Type that is added to the SerializationInfo, it has to be serialized, and then their Types, and so on so forth.   -----BEGIN GEEK CODE BLOCK----- Version: 3.21 GCS/G/MU d- s: a- C++++ UL@ P++(+++) L+(--) E--- W+++ N++ o+ K? w++++ O- M(+) V? PS-- PE Y++ PGP++ t++@ 5 X+++ R+@ tv+ b(-)>b++ DI++++ D+ G e++>+++ h---* r+++ y+++ -----END GEEK CODE BLOCK----- Re: Abstract, Interface, and Attribute bnieland8-Jan-04 6:50 bnieland 8-Jan-04 6:50  By decorating your class with the Serializable attribute you are just telling other classes that you pass it to that it is "auto-serializable", by which it is meant that it contains no volatile references (i.e. a SQLConnection object) or references to other classes that are not serializable. This way a remoting object (for example) knows that it does not need any special instructions to serialize/deserialize. DTrent Re: Abstract, Interface, and Attribute TuringTest18-Jan-04 7:46 TuringTest1 8-Jan-04 7:46  i hadn't thought about the volatile references, thanks! ________________________________________ Gosh, it would be awful pleas'n, to reason out the reason, for things I can't explain. Then perhaps I'd deserve ya, and be even worthy of ya.. if I only had a brain! Quoted-Printable Decoder 7-Jan-04 18:33 7-Jan-04 18:33  I was working on POP3 mail application. I'm able to implement the POP3 protocol and get the mails and attachments.. etc. But i'm unable to decode some of the mails encoded by Quoted-Printable Content-Transfer-Encoding. Please help ASAP. Re: Quoted-Printable Decoder Heath Stewart7-Jan-04 19:00 Heath Stewart 7-Jan-04 19:00  If you're looking for the rules for decoding quoted-printable encodings, see RFC 1521: http://www.ietf.org/rfc/rfc1521.txt, section 5.1. When you say you're unable to decode, is there some specific problem or are you just having problems with the rules required for decoding? The link above should help.   -----BEGIN GEEK CODE BLOCK----- Version: 3.21 GCS/G/MU d- s: a- C++++ UL@ P++(+++) L+(--) E--- W+++ N++ o+ K? w++++ O- M(+) V? PS-- PE Y++ PGP++ t++@ 5 X+++ R+@ tv+ b(-)>b++ DI++++ D+ G e++>+++ h---* r+++ y+++ -----END GEEK CODE BLOCK----- Re: Quoted-Printable Decoder Blue Tender7-Jan-04 19:23 Blue Tender 7-Jan-04 19:23  Thanks Heath for your reply. But.... I needed the code in C# for decoding Quoted-Printable text. Re: Quoted-Printable Decoder Heath Stewart8-Jan-04 3:57 Heath Stewart 8-Jan-04 3:57  Right, and there doesn't appear to be any examples you can use. There is one commercial ASP.NET emailing package that uses it but they didn't give any details. Hence the RFC link - it isn't hard to do, so you should be able to figure it out. Mostly, it's just replacing certain characters with their hexidecimal equivalents prefixed by an equal sign. Use a StringBuilder for optimal performance. Replace the characters as necessary and break the lines into 76 character sequences taking into account whether tabs or spaces must follow on the next line. There was only one example in C# I could find, and if my German is any good, it seems to have problems in a couple cases. I tried tranlating the page, but apparently it was pretty bad grammar to start off with and the translation didn't do very well: http://www.mail-archive.com/csharp.net@glengamoi.com/msg00571.html[^].   -----BEGIN GEEK CODE BLOCK----- Version: 3.21 GCS/G/MU d- s: a- C++++ UL@ P++(+++) L+(--) E--- W+++ N++ o+ K? w++++ O- M(+) V? PS-- PE Y++ PGP++ t++@ 5 X+++ R+@ tv+ b(-)>b++ DI++++ D+ G e++>+++ h---* r+++ y+++ -----END GEEK CODE BLOCK----- How can I get some objects like HttpContext when using SingleCall SAOS and does not host in IIS (with HttpChannel) sxbyl7-Jan-04 17:14 sxbyl 7-Jan-04 17:14  If I host the SingleCall SAOs in IIS, I can use HttpContext.Current to get current HttpContext in the calling method, so I can get some useful information. But if I host the remote objects in a console application for debug, HttpContext.Current is a null object. Can I get some object likes HttpContext when I do not host the objects in IIS in the calling method? I’ d not like to use CallContext cross Internet. Best Regards! Re: How can I get some objects like HttpContext when using SingleCall SAOS and does not host in IIS (with HttpChannel) Heath Stewart7-Jan-04 18:48 Heath Stewart 7-Jan-04 18:48  HttpContext has no context outside of ASP.NET. It is tightly coupled, therefore not usable outside the context of ASP.NET. You might consider designing your SAO to be a little more abstract and leave the details of what is required (say, a response Stream) to the host.   -----BEGIN GEEK CODE BLOCK----- Version: 3.21 GCS/G/MU d- s: a- C++++ UL@ P++(+++) L+(--) E--- W+++ N++ o+ K? w++++ O- M(+) V? PS-- PE Y++ PGP++ t++@ 5 X+++ R+@ tv+ b(-)>b++ DI++++ D+ G e++>+++ h---* r+++ y+++ -----END GEEK CODE BLOCK----- Re: How can I get some objects like HttpContext when using SingleCall SAOS and does not host in IIS (with HttpChannel) sxbyl7-Jan-04 19:00 sxbyl 7-Jan-04 19:00  Thank for your comment. I only need some way to distinguish clients in my SingleCall objects, but I'd not like to pass the client id in all class methods, or to pass the id in CallContext. Re: How can I get some objects like HttpContext when using SingleCall SAOS and does not host in IIS (with HttpChannel) Heath Stewart7-Jan-04 19:03 Heath Stewart 7-Jan-04 19:03  Define "client ID". We use a lot of remoting in our application and deal with lots of stuff like that. I just need to understand your circumstances. Is it unique to a machine (perhaps an IP address)? A user identity? A client application version or client name (like a user agent for browsers)?   -----BEGIN GEEK CODE BLOCK----- Version: 3.21 GCS/G/MU d- s: a- C++++ UL@ P++(+++) L+(--) E--- W+++ N++ o+ K? w++++ O- M(+) V? PS-- PE Y++ PGP++ t++@ 5 X+++ R+@ tv+ b(-)>b++ DI++++ D+ G e++>+++ h---* r+++ y+++ -----END GEEK CODE BLOCK----- Re: How can I get some objects like HttpContext when using SingleCall SAOS and does not host in IIS (with HttpChannel) sxbyl7-Jan-04 19:18 sxbyl 7-Jan-04 19:18  In my software, I only need to distinguish sessions in the method calls. So I can generate a GUID in the client. But how can I passed to the server in SingleCall objects?

Last Visit: 31-Dec-99 18:00     Last Update: 25-Apr-24 11:41 Refresh ᐊ Prev1...14279142801428114282142831428414285142861428714288 Next ᐅ

General    News    Suggestion    Question    Bug    Answer    Joke    Praise    Rant    Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.