I think you have a basic lack of understanding of a couple of things:
1) How much work it takes to get a specific missions set up. Even assuming there was a spare Delta IV lying around (which there wasn't), you'd need a special design to carry the supplies, and the ability to get it set up and checked out very quickly.
Rockets are not airliners. Even for expendables, it takes weeks to get a launch ready.
2) Getting from one orbit to another is very expensive in terms of energy. ISS is at a higher altitude and a higher orbital inclination than typical shuttle flights, and getting from one to another takes way way too much fuel.
3) (Three! three things!) The Soyuz that's at ISS can only be used for re-entry. It doesn't have any cross-orbit capability. Not to mention that you'd be taking the Soyuz away from the ISS astronauts, who might use it.
There are always failure scenarios where there's nothing you can do.
If you want to specify the information, you can. If you don't, you don't have to. But I thought that would be obvious in the design of the XML serializer; you set the name if you care, and if you don't, it uses the reasonable default.
On your final statement, how do you propose to add attributes if you don't control the language, and can't forsee the future?
Attributes aren't really the C# version of reflection; reflection lets you look at the normal things you'd expect it to, and it also lets you look for attributes.
Why should you care?
Well, attributes are really useful in cases where you want to pass some information about the class somewhere else but you don't want to make it part of the code.
With attributes, for example, you can specify how a class should be persisted to XML.
[XmlRoot("Order", Namespace="urn:acme.b2b-schema.v1")]
public class PurchaseOrder
{
[XmlElement("shipTo")] public Address ShipTo;
[XmlElement("billTo")] public Address BillTo;
[XmlElement("comment")] public string Comment;
[XmlElement("items")] public Item[] Items;
[XmlAttribute("date")] public DateTime OrderDate;
}
At runtime, the XML serializer looks for those attributes on the object it's trying to serialize, and uses them to control how it works.
You can also use attributes to communicate marshalling information, security information, etc.
The nice thing about attributes is that it's a common mechanism, and it's extensible, so you don't have to invent some new mechanism to do something similar.
Or, to look at it another way, attributes are just a general mechanism for getting information into the metadata.
Integrating techology (and by this they mean computers) into the curriculum is currently in vogue in the educational establishment. Teachers are pushed to use computers in their classroom even if they don't have much utility. You could use a computer to record data and plot it for a physics experiment, or you could use a lab notebook. In the real world, you'd use a lab notebook, because notebooks are legal documents that you save. Why? Well, it's because the people pushing the technology don't understand the technology.
"Won't get fooled again" comes in three versions. There's a radio version, that's really short. There's the "Long Version" on Who's Better, Who's Best (which is a good compilation). My CD has it at 3:37. And there's the "Extended Version" off of Who's Next, which comes in at 8:32, and is clearly the best version around.
I sympathize somewhat with a reaction against "the Perl Way"; it's certainly easy to write write-only code in Perl. But if you're thinking about using character indexing to break apart strings, you're using the wrong tool. Sure, you *can* write such code in Perl, but it's going to take longer, be more error prone, and be tougher to read. To use the power of a language, you need to adopt the proper idiom. Just like I expect C programmers to use pointers to char rather than indexing then as an array, I expect Perl programmers to use regular expressions to break string rather than index and substr. If you're not going to use regex, why are you using Perl?
If you're going to do ASP, you can run PerlScript, and get all the nice Perl features from within the ASP environment. This is especially nice if you need to do complex database stuff. More information here: http://www.fastnetltd.ndirect.co.uk/Perl/Articles/ PSIntro.html
Slashdot Mirror
Umm...
I think you have a basic lack of understanding of a couple of things:
1) How much work it takes to get a specific missions set up. Even assuming there was a spare Delta IV lying around (which there wasn't), you'd need a special design to carry the supplies, and the ability to get it set up and checked out very quickly.
Rockets are not airliners. Even for expendables, it takes weeks to get a launch ready.
2) Getting from one orbit to another is very expensive in terms of energy. ISS is at a higher altitude and a higher orbital inclination than typical shuttle flights, and getting from one to another takes way way too much fuel.
3) (Three! three things!) The Soyuz that's at ISS can only be used for re-entry. It doesn't have any cross-orbit capability. Not to mention that you'd be taking the Soyuz away from the ISS astronauts, who might use it.
There are always failure scenarios where there's nothing you can do.
If you want to specify the information, you can. If you don't, you don't have to. But I thought that would be obvious in the design of the XML serializer; you set the name if you care, and if you don't, it uses the reasonable default. On your final statement, how do you propose to add attributes if you don't control the language, and can't forsee the future?
In the .Net implementation of C#, the garbage collector is in the runtime, and is used by all the .Net languages.
Value types are allocated inline, which means either on the stack or contained within an object.
If, for example, you allocate an array of 1000 value types, you're allocating 1 chunk of memory that's big enough to hold all 1000 objects.
If you do that with a reference type, you get an array of 1000 references to 1000 independently-allocated objects.
Attributes aren't really the C# version of reflection; reflection lets you look at the normal things you'd expect it to, and it also lets you look for attributes.
Why should you care?
Well, attributes are really useful in cases where you want to pass some information about the class somewhere else but you don't want to make it part of the code.
With attributes, for example, you can specify how a class should be persisted to XML.
[XmlRoot("Order", Namespace="urn:acme.b2b-schema.v1")]
public class PurchaseOrder
{
[XmlElement("shipTo")] public Address ShipTo;
[XmlElement("billTo")] public Address BillTo;
[XmlElement("comment")] public string Comment;
[XmlElement("items")] public Item[] Items;
[XmlAttribute("date")] public DateTime OrderDate;
}
At runtime, the XML serializer looks for those attributes on the object it's trying to serialize, and uses them to control how it works.
You can also use attributes to communicate marshalling information, security information, etc.
The nice thing about attributes is that it's a common mechanism, and it's extensible, so you don't have to invent some new mechanism to do something similar.
Or, to look at it another way, attributes are just a general mechanism for getting information into the metadata.
Integrating techology (and by this they mean computers) into the curriculum is currently in vogue in the educational establishment. Teachers are pushed to use computers in their classroom even if they don't have much utility. You could use a computer to record data and plot it for a physics experiment, or you could use a lab notebook. In the real world, you'd use a lab notebook, because notebooks are legal documents that you save. Why? Well, it's because the people pushing the technology don't understand the technology.
"Won't get fooled again" comes in three versions. There's a radio version, that's really short. There's the "Long Version" on Who's Better, Who's Best (which is a good compilation). My CD has it at 3:37. And there's the "Extended Version" off of Who's Next, which comes in at 8:32, and is clearly the best version around.
I sympathize somewhat with a reaction against "the Perl Way"; it's certainly easy to write write-only code in Perl. But if you're thinking about using character indexing to break apart strings, you're using the wrong tool. Sure, you *can* write such code in Perl, but it's going to take longer, be more error prone, and be tougher to read. To use the power of a language, you need to adopt the proper idiom. Just like I expect C programmers to use pointers to char rather than indexing then as an array, I expect Perl programmers to use regular expressions to break string rather than index and substr. If you're not going to use regex, why are you using Perl?
If you're going to do ASP, you can run PerlScript, and get all the nice Perl features from within the ASP environment. This is especially nice if you need to do complex database stuff. More information here: http://www.fastnetltd.ndirect.co.uk/Perl/Articles/ PSIntro.html