From: Peter Date: 2005-01-06T07:21:08+09:00 Subject: Re: Allowing custom number literal suffixes? --981873195-1831412231-1104963654=:23913 Content-Type: MULTIPART/MIXED; BOUNDARY="981873195-1831412231-1104963654=:23913" This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --981873195-1831412231-1104963654=:23913 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > Is there a parsing ambiguity that would result from allowing a suffix > to be any legal method identifier? This certainly would result in more > readable code and far less chance that different libraries would attempt to > define literals with the same suffix. There's no problem with allowing any method identifier as suffix from the parsing point of view. A possible implementation is attached. "1:10"PM calls String::Literal::PM("1:10"). It is implemented differently than the patch for number literal suffixes which shows in the fact that there can be a space between the string and the suffix, and that a suffix like 'class' won't work because 'class' is a reserved word. This was the easy implementation... Funny thing: "1:10"methods calls String::Literal::methods("1:10") which happily returns all methods in String::Literal. That's the downside of using the unchanged suffix as method name. Peter --981873195-1831412231-1104963654=:23913 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=string-literals-patch Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename=string-literals-patch LS0tIHBhcnNlLnkJMTMgT2N0IDIwMDQgMTk6NDY6NDAgLTAwMDAJMS4xLjEu MQ0KKysrIHBhcnNlLnkJNSBKYW4gMjAwNSAyMjowMzoxOSAtMDAwMAkxLjEu MS4xLjI0LjENCkBAIC0xOTEzLDYgKzE5MTMsMTcgQEANCiAJCQkgICAgbm9k ZSA9IGV2c3RyMmRzdHIobm9kZSk7DQogCQkJfQ0KIAkJCSQkID0gbm9kZTsN CisJCSAgICB9DQorICAgICAgICAgICAgICAgIHwgc3RyaW5nIHRJREVOVElG SUVSDQorCQkgICAgew0KKwkJCU5PREUgKm5vZGUgPSAkMTsNCisJCQlpZiAo IW5vZGUpIHsNCisJCQkgICAgbm9kZSA9IE5FV19TVFIocmJfc3RyX25ldygw LCAwKSk7DQorCQkJfQ0KKwkJCWVsc2Ugew0KKwkJCSAgICBub2RlID0gZXZz dHIyZHN0cihub2RlKTsNCisJCQl9DQorCQkJJCQgPSBORVdfQ0FMTChORVdf TElUKHJiX21TdHJpbmdMaXRlcmFsKSwgJDIsIE5FV19MSVNUKG5vZGUpKTsN CiAJCSAgICB9DQogCQk7DQogDQotLS0gcnVieS5oCTEzIE9jdCAyMDA0IDE5 OjQ3OjAwIC0wMDAwCTEuMS4xLjENCisrKyBydWJ5LmgJNSBKYW4gMjAwNSAy MjowMzoxOSAtMDAwMAkxLjEuMS4xLjI0LjENCkBAIC01NjUsNiArNTY1LDcg QEANCiBSVUJZX0VYVEVSTiBWQUxVRSByYl9tR0M7DQogUlVCWV9FWFRFUk4g VkFMVUUgcmJfbU1hdGg7DQogUlVCWV9FWFRFUk4gVkFMVUUgcmJfbVByb2Nl c3M7DQorUlVCWV9FWFRFUk4gVkFMVUUgcmJfbVN0cmluZ0xpdGVyYWw7DQog DQogUlVCWV9FWFRFUk4gVkFMVUUgcmJfY09iamVjdDsNCiBSVUJZX0VYVEVS TiBWQUxVRSByYl9jQXJyYXk7DQotLS0gc3RyaW5nLmMJMTMgT2N0IDIwMDQg MTk6NDc6MTQgLTAwMDAJMS4xLjEuMQ0KKysrIHN0cmluZy5jCTUgSmFuIDIw MDUgMjI6MDM6MjAgLTAwMDAJMS4xLjEuMS4yNC4xDQpAQCAtMjYsNiArMjYs NyBAQA0KICNlbmRpZg0KIA0KIFZBTFVFIHJiX2NTdHJpbmc7DQorVkFMVUUg cmJfbVN0cmluZ0xpdGVyYWw7DQogDQogI2RlZmluZSBTVFJfQVNTT0MgICBG TF9VU0VSMw0KIA0KQEAgLTQ2NzUsNCArNDY3Niw2IEBADQogICAgIHJiX2Zz ID0gUW5pbDsNCiAgICAgcmJfZGVmaW5lX3ZhcmlhYmxlKCIkOyIsICZyYl9m cyk7DQogICAgIHJiX2RlZmluZV92YXJpYWJsZSgiJC1GIiwgJnJiX2ZzKTsN CisNCisgICAgcmJfbVN0cmluZ0xpdGVyYWwgPSByYl9kZWZpbmVfbW9kdWxl X3VuZGVyKHJiX2NTdHJpbmcsICJMaXRlcmFsIik7DQogfQ0K --981873195-1831412231-1104963654=:23913-- --981873195-1831412231-1104963654=:23913--