I have strong reservations about hard-coded URLs as an SDLC wreck waiting to happen, but the world of mid-day build and deploy might mitigate this, except when the developers are laid off and an acquisition or service consolidation causes a domain or URL change. Having seen this many times I have always put URLs in a properties file for bootstrapping, and a database for post-bootstrap. This allows per-instance customization and live instance changes which is also usually necessary.
It would be a good idea for literals of different types to be easily
recognizable in the source by human readers and extractable from the source
by tools. I'm sure everyone agrees that it's annoying/risky when you can't
even distinguish localizable strings (user messages) from non-localizable
strings. I'm in support of the (separate) concepts of 1) better compile
time support for URLs and 2) better compile time support for user code
(literal parsing; constexpr; macros). I hope the solution will consider how
refactoring tools can extract literal URLs from the source and replace with
URLs read from a configuration.
I won't risk derailing the thread completely by going in to detail, but
when I think of better compile-time support for URLs, the features that I
first think of are:
1) A specific subtype for URLs in a protocol family:
a) Local File URLs
b) "Web URLs" (specifically HTTP & HTTPS)
2) A specific subtype for absolute URLs
Those are library-level concerns, but I mention them so that anyone with a
general interest in improving compile time support for URLs might have a
chance of finding them.
-- Callionica
路路路
On Sat, Dec 17, 2016 at 9:23 AM, Stephen Buck via swift-evolution < swift-evolution@swift.org> wrote:
I like the David Sweeris idea best. The syntax is cleaner and the type URL
"knows what to do with itself".
I have strong reservations about hard-coded URLs as an SDLC wreck
waiting to happen, but the world of mid-day build and deploy might mitigate
this, except when the developers are laid off and an acquisition or service
consolidation causes a domain or URL change. Having seen this many times I
have always put URLs in a properties file for bootstrapping, and a database
for post-bootstrap. This allows per-instance customization and live
instance changes which is also usually necessary.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
I suppose if compile time validation is desired I guess we can do something
similar to @ibdesignables. Except instead of live rendering UIViews we
would render the url
Marking a URL like this @urlvalidation("a URL string")
Would make it fire a compiletime URL request and give a warning if it was a
bad URL but if it is a good URL then it returns a URL instance
路路路
On Sat, Dec 17, 2016 at 1:02 PM Callionica (Swift) via swift-evolution < swift-evolution@swift.org> wrote:
It would be a good idea for literals of different types to be easily
recognizable in the source by human readers and extractable from the source
by tools. I'm sure everyone agrees that it's annoying/risky when you can't
even distinguish localizable strings (user messages) from non-localizable
strings. I'm in support of the (separate) concepts of 1) better compile
time support for URLs and 2) better compile time support for user code
(literal parsing; constexpr; macros). I hope the solution will consider how
refactoring tools can extract literal URLs from the source and replace with
URLs read from a configuration.
I won't risk derailing the thread completely by going in to detail, but
when I think of better compile-time support for URLs, the features that I
first think of are:
1) A specific subtype for URLs in a protocol family:
a) Local File URLs
b) "Web URLs" (specifically HTTP & HTTPS)
2) A specific subtype for absolute URLs
Those are library-level concerns, but I mention them so that anyone with a
general interest in improving compile time support for URLs might have a
chance of finding them.
-- Callionica
On Sat, Dec 17, 2016 at 9:23 AM, Stephen Buck via swift-evolution < > swift-evolution@swift.org> wrote:
I like the David Sweeris idea best. The syntax is cleaner and the type URL
"knows what to do with itself".
I have strong reservations about hard-coded URLs as an SDLC wreck
waiting to happen, but the world of mid-day build and deploy might mitigate
this, except when the developers are laid off and an acquisition or service
consolidation causes a domain or URL change. Having seen this many times I
have always put URLs in a properties file for bootstrapping, and a database
for post-bootstrap. This allows per-instance customization and live
instance changes which is also usually necessary.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
wreck waiting to happen, but the world of mid-day build and deploy might mitigate this, except when the developers are laid off and an acquisition or service consolidation causes a domain or URL change. Having seen this many times I have always put URLs in a properties file for bootstrapping, and a database for post-bootstrap. This allows per-instance customization and live instance changes which is also usually necessary.