Linuxは、開発環境が40年前と同レベル

間違ってもらっては困るのは、それはコマンドライン・メインなのが主因ではないということ。
本当の一因は、本来手書きでも簡単な Makefile の作成をわざわざ難しくしてしま
う autotools を権威に流されたのか多くのプロジェクトが使ってしまっている事にある。
高々 Makefile 1つ作るためにも以下のような工程を踏まなければならない。
本来、典型的には、ソースファイルである *.c, *.cxx, *.cpp を指定するだけ
でも自動生成する事が出来るはずなのに、ツール類が馬鹿だからそうなってない。
なのに、「Linuxはプログラマーには便利」などと嘘情報が流れるから、普及しない。
しかも、カレントディレクトリのスクリプトの実行に「./configure」などと「./」
の指定が必要なのも馬鹿丸出し。ファイル名に大文字小文字の区別がされているのも馬鹿。
ファイルのコピーもdosなら、「copy *.c /xxx/aaa 」で済むことが
$ find . -name '*.c' | xargs -n 1 -i cp -p {} /xxx/aaa
などとしなくてはならず長すぎ、馬鹿ですか？ しかも、'*.c'の部分が、*.c と書かれている
説明が溢れているがそれだとbashが展開してしまうのでたまたま上手く行く事はあっても、
実際には正しくない。また、mountしないとディスクが認識出来ないのも初代PC-8001の
レベル。PC-8801で自動マウントできるようになったのに（いつの時代（苦笑））。まずは、
不便さを認めるなければ、改善すらままならないのにそれすら全否定。正直に便利と思って
るなら井の中の蛙で馬鹿で無知なだけだ。そして、僅か１点でも間違いがあれば全てが間違って
いるように全否定してしまうLinux信奉者の愚かさもアホとしか言いようがない。

自分ではどうしてるの? もちろん実践してるよね?

>>486
> 設定ツールが設定ファイルをどう扱うかうか怪しいのに
> アプリが設定ファイル読み込んでちゃんと設定値の利用できるんだろうか

まさかと思うけど、設定ツールで設定したら、設定ファイルが
壊れちゃったとかそういう事考えてる？　それってテキストエディタで
編集したらファイルが壊れたみたいなことと同じこと言ってるよ

設定ツールは何もデータを変更せずに保存すれば設定ファイルは何も変更しない
設定ツールが変更できるのは<input>とか<select>とか設定値として使用する要素だけ
さすがにこれぐらいは決めるよ。決めるっていうかガイドラインだね。

アプリが設定値として利用するのは<input>とか<select>とか設定値として使用する要素だけ
これらの要素の名前を値を利用する。DOMの構造は設定値としては不要な情報なので無視する。
だから構造をガラッとかえても、名前と値が同じならアプリからは同じ設定に見える

>>487
「なら助かるけど」も「でも全く問題ない」も両方とも問題がある。

設定の名前（つまりfoo, bar, baz）をタグにするから
汎用の設定ツールで扱うことができないんだよ
だって、<foo>、<bar>、<baz>をどういうタイプとして扱うかなんてわからないでしょ

その使い方が間違ってると言ってるわけ。
でもやっぱりそういう使い方をするもんだって思い込んじゃってるんだよね・・・
発想が凝り固まってるのはどうしようもないんかねｗ

じゃあどうすんの？って話なんだろうけど、すでに上の方でも書いてるけどこんな感じね

<configurations type="Configurations">
　<label>foo: <input name="foo" type="int" value="1" /></label>
　<label>Items: <input name="bar" type="Items" value="item1" /></label>
　<label>baz: <input name="baz" type="bool" value="true" /></label>
</configurations>

そうすりゃ設定ツールは、fooという未知のタグをどう表示すりゃいいんだ？なんて悩むことはなく
あ、はいはい、inputタグね。これはユーザーの入力項目ですね。intですね。なら数値フィールドですね。
数値以外は入れられないようにしますよ。なんなら上下ボタンで値の増減もしますよ。
みたいに理解できる。

ちなみに上の例にはわざと<label>を追加してる。なぜかというと設定ファイルにあるタグはすべてが
入力項目とは限らないからだ。既存の設定ファイルでもコメントでどんな値を入力すればいいかなどの説明が書いてあるだろ？
すべてのタグを入力項目として扱えない。どうせそのことが抜け落ちてるんだろうからさ

>>489
>>490
色々できることが増えてきたけど
何ができるとか何をして良いとか何をしてはいけないとか
どうやって決めるんだろう

425 login:Penguin sage 2018/09/16(日) 20:03:57.41 ID:29LJB/lv
そりゃ規格なんだからある程度の量にはなるが、
基本はXMLなのでXMLとしての仕様は不要
タグ一覧があれば十分だろ
少なくともHTMLの仕様よりは大きくならない

>>491
> 色々できることが増えてきたけど
> 何ができるとか何をして良いとか何をしてはいけないとか
> どうやって決めるんだろう

誰かが決めれば？
俺は、世の中はXMLの使い方を間違ったよなーって話をしてるだけ

>>220より

>>216
何の意味って、最初に言ったとおり、
世の中はXMLの使い方を間違ったよなーって話をしてるだけ

>>217
標準化しようじゃなくて
世の中はXMLの使い方を間違ったよなーって話をしてるだけ

>>218
仕様を書く必要はないよ
世の中はXMLの使い方を間違ったよなーって話をしてるだけ

>>219
世の中はXMLの使い方を間違ったよなーって話をしてるだけ

あと、何度もコピペしてるけど

そりゃ規格なんだからある程度の量にはなるが、
基本はXMLなのでXMLとしての仕様は不要
タグ一覧があれば十分だろ
少なくともHTMLの仕様よりは大きくならない

HTMLの仕様は巨大で複雑。タグが省略できるなど
XMLに反してるのでそこまで決めなければならなかったし
HTML5では間違ったHTMLであってもすべてのブラウザで
同じように表示できるように不正なHTMLの解釈の方法まで定義された
汎用の設定ツールはXMLベースなので、そんなことは不要
XMLをベースにしてますの一言で、拡張部分（つまりタグ一覧）さえ決めれば良くなる

>>492
誰かが決めればってそれは規格を作成して決めなきゃいけない問題であるとの認識なのか
丸投げ逃亡宣言かどっち？

>>494
お前が技術的なメリットデメリットの話から、実現が大変かどうかの話に
すり替えようとしてるのには気づいているからさｗ

俺からすりゃ、大変だから何？　大変というのは俺が言ってる
世の中はXMLの使い方を間違ったなーという話への反論には
なってないでしょの一言で終わりだから

丸投げ逃亡宣言（笑）とか、結局技術的な話をしたいんじゃなくて
俺を論破（笑）したいだけなのモロバレだし
だから技術的な話から揚げ足取りできる方向にすり替えたいんだろうな

規格の制定が必要だと認識してるのかどうか答えられないの？

独自タグに溢れてるから間違いって主張は間違ってるじゃん

何度でも聞くけど
>>492
誰かが決めればってのは
・設定ツール作成や利用アプリの為に規格作成が必要
・規格なんか決めなくて実装者が好き勝手決めて思う通りやれば良い
・自分でも
何言ってるのか意味が

何度でも聞くけど
>>492
誰かが決めればってのは
・設定ツール作成や利用アプリの為に規格作成が必要
・規格なんか決めなくて実装者が好き勝手決めれば良い
・自分でも何言ってるのか意味がわからない
どれ？

だから決めるべきことがあれば、誰かが決めろって
俺は最初からずーっと
世の中はXMLの使い方を間違ったよなーって話をしてるだけ

>>493
XHTMLは「XMLを拡張して」作ったけどタグ一覧で済んでたかな

ひょっとして >>123 から始まってたのか? 今気付いた。
さすがにちょっと可哀想になってきたよ。
近くに君と会話できる人はいないのかい?

>>501
誰が何を決める想定なんだよ
決めるべき所は決めるじゃトートロジーだろ

>>502
> XHTMLは「XMLを拡張して」作ったけどタグ一覧で済んでたかな
XHTMLの話はしてない

>>503
数ヶ月あけてレス (>>177) が来たからね。
話を再開しただけ

> 近くに君と会話できる人はいないのかい?
それが技術的な話と何か関係ある？
もっというと、それは反論ではないよ。

>>504
> 誰が何を決める想定なんだよ
だからそんなの想定する必要がないってｗ
俺は最初からずーっと
世の中はXMLの使い方を間違ったよなーって話をしてるだけ


ほんとなぁ「XMLの使い方を間違った」という意見に対しての
技術的な反論してくれればいいのに、大変だろう？とか誰がやるんだよ？とか
無関係な話にすり替えて揚げ足撮ろうとしてるのミエミエだからｗ

仕事でも「解決すべき問題の認識」と「どうやって解決すべきか」は
分けて考えないといけない。

でないと、以下のようなシナリオが起きる

上司「なにか問題はありますか？」
部下「○○という問題があります？」

上司「誰が問題点を解決するんだ？そのコストがいくらかかる思ってるんだ？
お前責任取れるのか？その答えがでてないなら議題に上げるな」

こうやって問題があるのになかったことにされる。

優秀だが嫌味な部下「まず問題があるか無いかを決定する話をしましょう。
問題があることに異論はないわけですよね。では問題があるということは決定します。
そして、あなたは問題があると認識した上で誰が解決するのかとコストが不明という別の理由で
問題がなかったことにするのですか？おかしいですね。問題があることは決定したはずです。」

ミスったｗ

上司「なにか問題はありますか？」
部下「○○という問題があります」

部下が、聞いてどうするんだってなｗ

仕様をどう決めて何を実装すべきか言えないのに
今のソフトは間違ってる（笑）

>>505
XHTMLはタグ一覧ではすまなかったのかな？
設定XMLはタグ一覧で済む理由あるのかなあ（爆）

世間のXMLの使い方は間違ってて設定XMLの先生が間違ってない理由は何さ（大爆笑）

>>509
根本的なところがずれてない？

http://jtdan.com/spec/ の中から
XHTML 1.0 拡張可能ハイパーテキスト・マークアップ言語 (第二版)
http://msugai.fc2web.com/web/W3C/xhtml1SE/Cover.html

XHTMLの仕様書ってこんだけだよ？ 意外と少ないでしょ。
誰かが電話帳ぐらいになるはずだとか言ってたけど。そんな量はない。

見ての通りHTMLとの互換性の話が含まれるから、XHTMLは量が多めだけど、
それでもこの程度、XML設定ファイルはこれよりも少ないってのは明らかだろうね

もしかしてA4用紙で3枚を超えたら多いとか思ってない？

>>510
> 世間のXMLの使い方は間違ってて設定XMLの先生が間違ってない理由は何さ（大爆笑）

間違ってるという（俺の）意見がある
その俺の意見に対して間違っているという意見がない

>>512
いや色々突っ込まれてることにお前が認識してないだけだろ

>>511
https://www.w3.org/TR/2002/REC-xhtml1-20020801/
原典だせないの？
これはタグの一覧に見えるのか？
お前のリファレンスのHTML4の差分という文章は？

>>512
お前の設定XML（笑）に賛同してくれる物好きいないから却下でいいんじゃないの（笑）

都合の悪い質問は無視して難癖できるとこだけ明後日の妄想続ける（爆）

>>505
間違ってるなら正しい使い方示せばいいのに
誰かが決めるべき所は決める（笑）

>>505
今のXMLが間違ってる以外の
ぼくのかんがえたさいきょうの設定XMLだの
設定ツールが作れるだのは思えの意見じゃ無いの？

何度も言ってるけど、xmlは異なるアプリ間やxmlを共有（feed利用）しない限り、
名前空間を定義（スキーマ）せずに使っても間違いとは言えない。
文法の誤りとかじゃなくて、設定ファイルなんかの特定のアプリ内で使うようなxmlに独自タグが入っててもいいだろ。

そもそも設定ファイルにxml使ってるようなアプリはエディタで編集されるのを想定してないからxml使ってるようなもん。
普通に使ってたら設定ファイルすらみない。
linux使っててbash書いたり、yml編集したり、config.jsonをエディタで編集してもxmlはguiで編集するのが多かった。
独自タグがあってもうまく隠されてて不都合が起きることはまずない。

だからxml君の主張は的外れだな。世間のxmlの使い方は間違ってない。
だいたい世間が使うときはFeedぐらいだしな。

お前らのXMLの使い方は間違ってる！
正しい使いかはこれだ（ボコボコに叩かれる）
いやーオレのXMLの使い方は間違ってるに誰も反論してないこれはオレの大勝利
こういうことですかね

fooの型ってなんだよ ← 分かる
boolだよ
boolって言ってもいろいろあるだろ ← 分かる
true/falseの大文字小文字区別なし、[Tr][Rr][Uu][Ee]だね
radioboxか？checkboxか？selectboxか？何で扱えばいいんだ？ ← 分からない
好きにしろよ…

間違ってる使い方（>>487）と正しい使い方の例

>>487
「なら助かるけど」も「でも全く問題ない」も両方とも問題がある。

設定の名前（つまりfoo, bar, baz）をタグにするから
汎用の設定ツールで扱うことができないんだよ
だって、<foo>、<bar>、<baz>をどういうタイプとして扱うかなんてわからないでしょ

その使い方が間違ってると言ってるわけ。
でもやっぱりそういう使い方をするもんだって思い込んじゃってるんだよね・・・
発想が凝り固まってるのはどうしようもないんかねｗ

じゃあどうすんの？って話なんだろうけど、すでに上の方でも書いてるけどこんな感じね

<configurations type="Configurations">
　<label>foo: <input name="foo" type="int" value="1" /></label>
　<label>Items: <input name="bar" type="Items" value="item1" /></label>
　<label>baz: <input name="baz" type="bool" value="true" /></label>
</configurations>

そうすりゃ設定ツールは、fooという未知のタグをどう表示すりゃいいんだ？なんて悩むことはなく
あ、はいはい、inputタグね。これはユーザーの入力項目ですね。intですね。なら数値フィールドですね。
数値以外は入れられないようにしますよ。なんなら上下ボタンで値の増減もしますよ。
みたいに理解できる。

ちなみに上の例にはわざと<label>を追加してる。なぜかというと設定ファイルにあるタグはすべてが
入力項目とは限らないからだ。既存の設定ファイルでもコメントでどんな値を入力すればいいかなどの説明が書いてあるだろ？
すべてのタグを入力項目として扱えない。どうせそのことが抜け落ちてるんだろうからさ

全然話違うけど設定ファイルをスクリプトにするのってどう思う？

メリットもあればデメリットもある。いちいち騒ぐほどのことじゃない。

>>524
ドキュメントついててわかりやすかったらなんでも良いと思うよ。

設定ファイルとドキュメントは別にするべき？

>>527
誰に感化されているのか、本人なのか知らないが、
ドキュメントはあくまでドキュメント。インストール方法からアプリについて必要なことを書くべき。設定ファイルを含む。設定ファイルに書いてあるコメントだけで設定しようと言うやつはものぐさなだけ。
そもそも設定が必要なアプリもインストールと対して変わらないが。

>>528
そもそも設定ファイルにコメントっているの？

ドキュメントなんて基本、読まれない。だがそれでいいのだ。
http://el.jibun.atmarkit.co.jp/101sini/2016/07/post-f781.html

人類の9割はマニュアルやドキュメントを読まない
https://tora-sub.hatenablog.jp/entry/2018/01/29/212638

>>529
開発者が必要だと思ったら書く

>>531
「開発者が」か

やっぱりそこに開発者とユーザーの温度差を感じるんだよな
ドキュメントは読まなくても使えるようにするのが良いソフトなわけで
ドキュメントとついてるからOKだろって発想が
このスレに合わせて言うのなら思考回路が40年前と同じレベルｗ

設定はデフォルトで不満だったり、変更する必要がある時に変更するので、設定ファイルを編集する時点でドキュメントを読む必要がある。
これを読んだことがなく設定を変更するにはブログや本等の二次情報に頼るか、GUIの機能を使う。
設定ファイルのコメントが読まれる状況は本人か、ハードユーザーになるのでそれ向け。

一般に普及してるのはWindowsなのでドキュメント文化が根付いていないのは仕方ないと思うが、Linuxを使うのであれば、一次情報のドキュメントを読むべき。

Windowsはドキュメントが不十分すぎてoffice使うのも教室通ったり、本屋で本買ったりするだろ。
ドキュメントがるソフトであれば、それが不要になるてこと。それがオープンソース。
これは最大の強みだから昔と同じでいい。

>>533
例えば良いソフトってなんだ？

Windowsだからドキュメント文化がないんじゃなくて
家電でもスマホでもゲームでも自動車でも同じでしょ？

ドキュメント読まないと使えないから仕方なくドキュメント読むんやで

>>535
お前がドキュメント読まないで使ってるソフト
ブラウザとか５ちゃんねるブラウザとか
ほとんどのスマホアプリとか

>>534
マジレスするとWindowsの方がドキュメントは充実してる

>>537
ブラウザもスマホアプリも専ブラも始めに使い方を調べるだろ、もしくは小学校で学ぶ。パソコンが普及したときはクリックってなに？から始まったんだぞ。
直感的に使えるということであれば、他のアプリを真似て作ってるだけ。
家電の話でも使ったことないやつは洗濯もできないやついるだろ。ママに教わらないとできない。
ママが近くにいないときは取説を読め。

>>539
でもドキュメント読んだことないでしょ？
教室通ったり、本屋で本買ったりして使えるようになるんだから

>>540
全部のドキュメントを読むということはない。設定ファイルをいじるようなときにだけドキュメントを読むって話。拡大解釈してないか？

>>541
その読むべき項目が、設定ファイルの設定項目の上に
書いてあれば、便利じゃないですか？

>>542
便利だね。

俺が
>ドキュメントついててわかりやすかったらなんでも良いと思うよ。
って書いたのは、コメントでもなんでも文章で説明されてればってことなんで、単語に引っ張られてミスリードしないでくれ。
設定ファイルからコメントが取り除かれてる場合はハードユーザー以外はいじらないでくれって暗に示してる時もあるから絶対コメントがあったほうが良いって話じゃない。

開発環境が云々ってスレでドキュメントがあるアプリが良いって意見はそんなに不自然ではないと思うがな。
自分がしたい話題にのみ焦点を当てて他人のレスを曲解するのは良くないぞ。

設定する項目の上に、説明が書いていれば便利だけど
英語だったら便利さ半減なんだよな。読めない人が大半だし。
だからLinuxではみんな技術書を買って使い方を勉強するんだろう

LinuxはMacやWindowsと違って対象ユーザーが一般向けじゃないからな。
一般も別に使ってもいいけど、いじりたければ自己責任の世界だから。
ubuntuなんかは企業が入って開発者とユーザーの間に入っていろいろやってくれてるけど、無料じゃ限界があるだろ。

XMLおじさん死んだの？

いや、反論なくなったので書くことがないだけ

最後のレスは>>523かな？

>>522
>>523
あるタグならこう動作するこの属性はこう取り扱うなど記述してるけど
その取り決めは誰がするの？

例えばにはtype=intとあったときにintというのは整数型で実装すると判断する根拠はどこにあるのかな？

君の大好きなHTMLのサブセットには無さそう

>>551
取り決めを誰がするのかどうかの話は
技術的な話と何の関係があるの？

例えばJavaScriptのブラウザの新しいAPIの仕様の話をしているときに
取り決めは誰がするの？と言い出すことに何の意味があるの？

>>552
> 例えばにはtype=intとあったときにintというのは整数型で実装すると判断する根拠はどこにあるのかな？

あ、それは間違いでしたって>>523で訂正したよ。

type=intはデータ型に過ぎなくて、データ型の情報では
どういうインターフェースで入力するかは決定できない。

古き良き、テキストボックスで入力するかもしれないし
HTML5の数値専用のテキストボックス（数値増減の▲▼つき）かもしれないし
スライダーを使うかもしれない。なので汎用のXML設定ファイルには
データ型を記述することはない。
要するに「整数型で実装するという判断はすべきでない」が正解なんだわ

なぜならそもそも不要だからね。XMLでない設定ファイルだって、
log_level=[ここ] が整数型で実装するか文字型なのかって判断は必要ないでしょ？
今やってないのに、汎用のXML設定ファイルにした途端、必要になるなんておかしい。

>>554
では質問を変えて。
実装者が実装する参考資料として事前に取り決めつまり仕様書は必要なの？

>>555
それだとintとかいてあったらカレンダーが表示される
実装するのは禁止されてないと読めるけど？

>>557
だからintなんて書かないって言っただろ
お前が訂正するまで話は進めない

>>558
type=numberならOKなのか？

>>558
>>556は？

>>559
numberは変数の型じゃないからな

inputタグ（テキストボックス）を使いnumber（数値）を扱うための
インターフェースを使用しろって明示してあるんだから
カレンダーを使うやつなんていないだろう

>>556はこの話題の対象外です。

まあもちろん腐った実装がカレンダーを表示した所で
おかしな設定をしてしまうってだけ

汎用のXML設定ファイルじゃない場合を想像してみりゃわかる

log_level="2018-09-27"
こう書いてしまっただけのこと
あとはプログラム側で今までどおりエラーがでるだろう

いや関係あるだろ。
何の前提知識もない実装者が
これを見て
<label>foo: <input name="foo" type="number" value="1" />
numberが数値を意味するとか
テキストボックスでもよいスライダーでもよい
カレンダーはだめだという判断を下せる根拠はどこからくるの？

>>562
腐った実装という言葉を使うけど客観的に腐ってるか正しいか
どうやって判断するの？

>>563
え？なに？仕様書を作る必要があるって話をしてるの？
作ればいいだけじゃん。

>>565
それはずっと言ってるHTMLより小さいと想定する仕様書に全部含まれると考えている？

<input name="foo" type="number" value="1" />

inputはユーザーが入力する項目を示します。
type属性は入力する値の種類を意味します。
設置ツールは適切なインターフェースを使用してください

終わり。たったこれだけｗ

>>567
値の種類とは？何種類あるの？勝手に増やしていいの？
適切なとは？何が適切でないとどうやって判断するの？
疑問一杯で仕様書とか読んだことも無さそうにしか見えないけど？

>>567
このレベルが仕様だと思ってるようでは話が通じないわけだ

>>556
お前は何が言いたいんだ？

HTMLはXMLベースではないのだから「XMLの仕様に準拠します」と書くことができない。
だからXML相当の仕様に加え、XMLには不要なHTML独自の仕様がたくさん含まれてる
例えばタグを省略したときのルールや、不正なタグ場合の解釈の仕方などだ

汎用のXML設定ファイルには、XMLの仕様を含める必要がない
ただ一言「XMLの仕様に準拠しますと」書けばいい
汎用のXML設定ファイルの仕様だけあればいい

だからどう考えても、
HTMLの仕様の量　>　汎用のXML設定ファイルの仕様の量（XMLの仕様は含まない）
になるのは明白なんだが

>>568
だから、仕様を作るだけですよね？

>>569
何が足りないのか、言ってみたら？

その量がHTMLの仕様の量を超えるまで待ってるよｗ

>>567
アプリの作者からすると<foo>1</foo>で事足りる
設定ツールの作者からしても
input + number という無駄情報より
type="int" という型情報
のほうが正確というかそのものなのでありがたいな

>>572
そういうこというと汎用設定ツールが作れないだのXMLの使い方が間違ってるだの馬鹿にされて
破綻してる設定XML構想聞かされるぞ

つか未だにgconfだのdconfだのが一度も出てこないことに驚き

>>574
それはずっと思ってた。
XMLおじさんによる比較とかダメ出しとかねーのか？

>>572
> 設定ツールの作者からしても
> input + number という無駄情報より
> type="int" という型情報
> のほうが正確というかそのものなのでありがたいな

type=intとあったときにintというのはスライダーで実装すると判断する根拠はどこにあるのかな？

>>574
gconfやdconfは値を編集することはできるが、
どういった値（型ではないぞ。値の範囲や文字列の候補だ）が設定可能か？の情報や
どういうインターフェースで設定するのか？という情報が抜けてるので、
使いやすいツールにはできない

>>576
numberと書けばスライダーが出てくる理由がわからん

numberと書けばスライダーが出てくるなんて言ってないぞ？

話を整理しようか？

1. type="int" という型情報じゃスライダーと数値用テキストボックスの
どちらを出せばいいかわからない

このことから型情報ではダメであると理解できたはずだ。
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^


で、numberと書けばスライダーが出てくるかどうかだったな
HTMLを参考にしてると言っただろう？

http://www.htmq.com/html5/input.shtml

2. type="number" だと数値用のテキストボックス（相当のもの）
type="range" だとスライダー（相当のもの）が表示される
typeに書いているのは変数の型ではないことが理解できたかな？

>>579
例えばnumberで出てくる数値入力ボックスは
要求が整数か浮動小数点か区別できるの？

>>580
まずさ、君が理解しないといけないことは
XMLではない設定ファイルにデータの型情報を
書いてるものなんか無いって事実だよ。

そう。いらない。整数化浮動小数点数か区別する必要がない。

inifileに

[VM]
MemoryGB=1

とかあった時、MemoryGBが整数か浮動小数点数か区別できるの？
区別できないし区別する必要がないよね。
数値どころか文字だって書くことができる

>>581
テキストボックスがぼーんとあって何を入れるかわからないのに何が便利なの？

彼の目的は >>220 に書かれている。すべて、そのための妄想だ。
妄想だということを本人も >>180 で認めている。
まあ、それが彼のやりたいことだというなら仕方ないじゃないか。

afinity modeを実装すれば解決する。

>>582
> テキストボックスがぼーんとあって何を入れるかわからないのに何が便利なの？

はい。情報が型しかないとそうなりますよね。
だから型の情報はいらなくて、
「何を入れるか分かる情報」が必要なんですよ

すげー40年前と同じ話題してる。

>>576
アプリの作者からしたら
スライダーだろうがテキストエディタだろうが関係ないんだから関与する必要がない
ツール作者やその利用者が好きにしたらいいだけ

>inputはユーザーが入力する項目を示します。
>type属性は入力する値の種類を意味します。
>設置ツールは適切なインターフェースを使用してください
という軟着陸なアイデアは無意味なので無視するとして

アプリ作者の独断で
エディット、スピン、スライダー、ダイヤル…
数有るコントロールの種別の中から一つを決めたとしても
そのチョイスを万人が受け入れるはずがないし
そのチョイス自体負担だし選び直しでリビルドとかやってられない
それなら
int型です、UIはご自由に
と投げたほうがいい

そもそも
int型です
という情報すらも必要ない

それが必要だという人が勝手に調べりゃいいだけ